[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set environment variables inside created container #149

Open
anaderi opened this issue Sep 2, 2016 · 6 comments
Open

set environment variables inside created container #149

anaderi opened this issue Sep 2, 2016 · 6 comments
Assignees

Comments

@anaderi
Copy link
Member
anaderi commented Sep 2, 2016

Usecase: user spawns a container from OpenML platform. in order to submit results back, he has to supply a special user-specific key. Such key could be entered manually in the notebook, but it is cumbersome. Instead a key could be

  • specified as a profile variable (like in travis-ci), or
  • specified as an argument to everware HTTP request when it creates a container
@betatim
Copy link
Member
betatim commented Sep 2, 2016

Could we solve this via a OpenML authenticator? So you'd switch from github auth to openmlauth?

@betatim
Copy link
Member
betatim commented Sep 5, 2016

If you make a new authenticator then handling the API token is easy. The hub can then make requests to OpenML authenticated as the user. Similar to what is done for forking/pushing to repos on github.

@anaderi
Copy link
Member Author
anaderi commented Sep 6, 2016

these variables should be used not from the code of everware, but from user notebook instead. so decided that:

if one provides params=value in launch URL , those params get into environment
also could be string field (and list of already set variables) that user can specify at the same page as github repo is specified.
Anyway parameter parsing should be rather strict to avoid possible injections

@betatim
Copy link
Member
betatim commented Sep 7, 2016

To make it a little less scary (think a bit.ly like link where the parameters are hidden from the user) would be to prefix all the variables before injecting them.

@betatim
Copy link
Member
betatim commented Sep 7, 2016

This way evil people can't overwrite your PS1 but only EVR_PS1 or what ever variable they are specifying.

@anaderi
Copy link
Member Author
anaderi commented Sep 10, 2016

I wonder why CI severs like travis or circle don't see anything bad in overriding PS1? )
one upside of having variables without prefix is for example one can setup same variable in several systems (everware and travis) and his/her study would run equally on both systems. If we introduce prefix, he/she would have take care of this prefix inside travis, which would look rather cumbersome. in other words I'd stay for a bit without prefix and if it would hurt, introduce it afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants