-
Notifications
You must be signed in to change notification settings - Fork 134
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
Integration branch for next release #112
Conversation
- It would be possible to have exec_prefix use string formatting and the command itself use jinja2 formatting, and when combined the string formatting would fail. To handle this, template them separately and then concatenate.
- These options first appeared in dff4482 for SlurmSpawner - Add tests for this option - Not currently implemented for CondorSpawner, since it uses a different method using `bash -c`. It could be added there, but someone with local knowledge should do that.
- Existing keepvars will whitelist environment variables, but is all-or-nothing: you can't append to existing required environemnt variables that JupyterHub requires. - This allows a comma separated list of the same format as req_keepvars that gets appended to keepvars, with one extra comma between them.
…ency with spacing
…atch_script first
…on call signature For consistency with jupyterhub itself
- Reading from stdout and stderr separately can produce a deadlock. I assume that the separate proc.wait_for_exit() doesn't matter here. - Thanks to @krinsman in jupyterhub#90.
…_debug', 'keepvars_extra', 'spawner_detail', 'prologue_epilogue' and 'exec_prefix_template_separately' into dev
Conflicts: .travis.yml (keep travis_jh9.0.1 side)
- Previously, only the query command got the full enivornment. - If this is used to authenticate to the submit/query/cancel commands, then the user's environment gets this also. - Closes: jupyterhub#108
Conflicts: batchspawner/batchspawner.py
Conflicts: batchspawner/batchspawner.py batchspawner/tests/test_spawners.py
@rkdarst I appreciate the work that you are doing to push the release forward. I'm a bit confused why move to an integration branch for development instead of merging existing PRs. Perhaps I'm missing some subtle interactions between PRs. We've typically cut releases from the master branch. I'm copying @minrk for his thoughts. I'm sorry that I've been a bit out of the loop recently with teaching, travel and vacation taking me away from the day-to-day dev stuff. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @rkdarst. I've made a few suggestions.
|
||
before_install: | ||
- npm install -g configurable-http-proxy | ||
- git clone --quiet --depth 1 https://github.com/minrk/travis-wheels travis-wheels | ||
- git clone --quiet --branch $JHUB_VER https://github.com/jupyter/jupyterhub.git jupyterhub | ||
install: | ||
# Don't let requirements pull in tornado 5 yet except for jupyterhub master | ||
- if [ $JHUB_VER != "master" -a $JHUB_VER != "0.9.0b2" ]; then pip install "tornado<5.0"; fi | ||
- if [ $JHUB_VER != "master" -a $JHUB_VER != "0.9.1" ]; then pip install "tornado<5.0"; fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to update the comment here to add clarity that 0.9.0 and later should install tornado>=5.0. This line should be updated as well.
README.md
Outdated
|
||
Unless otherwise stated for a specific spawner, assume that spawners | ||
*do* evaluate shell environment for users and thus the [security | ||
requriemnts of JupyterHub security for untrusted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: requirements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, updated.
README.md
Outdated
*do* evaluate shell environment for users and thus the [security | ||
requriemnts of JupyterHub security for untrusted | ||
users](https://jupyterhub.readthedocs.io/en/stable/reference/websecurity.html) | ||
are not fulfilled. This is something which we are working on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably be a bit more precise as to what is not fulfilled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! done.
README.md
Outdated
@@ -146,6 +157,14 @@ clusters, as well as an option to run a local notebook directly on the jupyterhu | |||
* Add new option exec_prefix, which defaults to `sudo -E -u {username}`. This replaces explicit `sudo` in every batch command - changes in local commands may be needed. | |||
* Add many more tests. | |||
* Update minimum requirements to JupyterHub 0.8.1 and Python 3.4. | |||
* New option: `req_keepvars_extra`, which allows keeping extra variables in addition to what is defined by JupyterHub itself (addition of variables to keep instead of replacement). #99 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To help the end user, we should divide into subsections: Added, Changed, Fixed, Removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in the changelog PR.
SPAWNERS.md
Outdated
# Checklist for making spawners | ||
|
||
- Does your spawner read shell environment before starting? (See | ||
[Jupyterhub Security](https://jupyterhub.readthedocs.io/en/stable/reference/websecurity.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, please add documentation so that the user is aware of this possibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Added as a note at the start of the section.
batchspawner/batchspawner.py
Outdated
"""Add user environment variables""" | ||
"""Add user environment variables. | ||
|
||
Everything here should be passed to the user's job. If it is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All user environment variables will be passed to the user's job.
Caution: If these variables are used for authentication to the batch system commands as an admin,
be aware that the user will receive access to these as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This had made me realize one possible solution is to separate req_keepvars and get_env more. Right now they are basically the same, but by using them more cleverly we can separate admin variables and user variables. It's already possible in fact, but not very convenient. Will comment in the other security tracking issue.
).tag(config=True) | ||
|
||
req_srun = Unicode('srun', | ||
help="Job step wrapper, default 'srun'. Set to '' you do not want " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps: Set req_srun=''
to disable running in job step, and note that this affects environment handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks.
I agree that it is better to merge PRs individually. But... PRs are not really merged or commented on. Practically everything in here was a separate pull request that doesn't seem to have any objections, and it got to the point where things can not be tested individually anymore (for example, #110 means all tests break, several of these resulted in merge conflicts). I'm trying to keep everything separated into branches as much as possible, and I'm happy to do enough git magic to separate out again if someone would like. You can review all of the separate PRs instead of this branch, and internally I will keep this up to date and tested. Also, if someone merges all of the other separate PRs, this PR becomes obsolete (but that will require manual merging in some places). Thanks for the reviews! I will go update the individual branches and re-merge into here. |
Also I need to make a new branch to test locally anyway, and i I will be doing that work, may as well make it public to save effort... dealing with long-running branches is not one of my favorite things to do. |
- Thanks to @willingc for the suggestion.
Thanks for getting this started! I think we should land this one to keep things moving, and try to stay more on top of individual PRs in the future. Whenever folks are depending on multiple unmerged PRs, things get tricky. |
Thanks @rkdarst for persisting and keeping this moving. |
Agreed. Thanks to everyone for the help in keeping things moving! |
I started this as integration branch of all patches for next release. Not everything is here yet, but I will try to integrate on here. Feedback from community about what to integrate is welcome.
I will use #103 to list what is integrated into this already.
Runs OK on my dev instance. Let's see if tests pass.