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

Integration branch for next release #112

Merged
merged 36 commits into from
Aug 10, 2018
Merged

Integration branch for next release #112

merged 36 commits into from
Aug 10, 2018

Conversation

rkdarst
Copy link
Contributor

@rkdarst rkdarst commented Aug 7, 2018

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.

Gwen and others added 29 commits June 15, 2018 17:02
- 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.
…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
@willingc willingc requested a review from minrk August 8, 2018 00:44
@willingc
Copy link
Contributor

willingc commented Aug 8, 2018

@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.

Copy link
Contributor

@willingc willingc left a 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
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: requirements

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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).
Copy link
Contributor

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.

Copy link
Contributor Author

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.

"""Add user environment variables"""
"""Add user environment variables.

Everything here should be passed to the user's job. If it is
Copy link
Contributor

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.

Copy link
Contributor Author

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 "
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks.

@rkdarst
Copy link
Contributor Author

rkdarst commented Aug 8, 2018

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.

@rkdarst
Copy link
Contributor Author

rkdarst commented Aug 8, 2018

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.

@minrk
Copy link
Member

minrk commented Aug 10, 2018

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.

@minrk minrk merged commit 4747946 into jupyterhub:master Aug 10, 2018
@willingc
Copy link
Contributor

Thanks @rkdarst for persisting and keeping this moving.

@mbmilligan
Copy link
Member

Agreed. Thanks to everyone for the help in keeping things moving!

@rkdarst rkdarst deleted the dev branch August 11, 2018 08:52
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

Successfully merging this pull request may close these issues.

6 participants