use COPY --chown to stage repo (docker 17.09)

[minrk]

Right now, we copy and chown the repo in two layers, which doubles the size the repo takes up in the env. This used to be required. Docker 17.09 adds support for COPY --chown to do it in one layer. So we can do this when it becomes okay to require docker 17.09 as the base version.

[mukundans91]

Can we add the functionality now with a check done to see if the underlying docker version is >= 17.09, if so use COPY --chown else use the older form of the template?

[minrk]

Good idea! We can indeed do that.

[willingc]

Adding this to the next release as this seems pretty straightforward.

[choldgraf]

I'm moving this to milestone v0.7, since we've already released v0.6 and this issue doesn't seem to be in it!

[betatim]

What does it mean if something is added to a milestone?

Should we make it to mean that we will wait to release the next version until this is done or do we take it as an indication that it would be a good fit in the next release (it isn't too early to work on this) but release will happen if no one works on it?

[choldgraf]

in other projects that I work on, the milestone issues are blocking on a release, though often people decide to punt them to the next release once it gets closer to deadline time

[betatim]

I think we should use it like that too (if it is in a milestone then the release waits till it is done). Maybe we can ease into it by only adding things to a milestone a few days before a release as a kind of todo list/making sure we don't forget something. With the current state of contributors I worry that if we add something to a milestone that isn't security or usability critical (and hence has a high likelihood of getting worked on) we will end up punting a lot or slow down our releases even more :-/

[Xarthisius]

Just as a note: an implementation of COPY --chown that expands variables in options was merged only two weeks ago (see moby/moby#35018 (comment)). Now it's going to be possible to actually do:

COPY --chown=${NB_USER}:${NB_USER} src/ ${REPO_DIR}

[yuvipanda]

Me and @jhamman found out that version of docker used by GKE does not support this yet, so the default install of BinderHub can't use it (since it uses the same docker as the underlying cluster)

[minrk]

in other projects that I work on, the milestone issues are blocking on a release, though often people decide to punt them to the next release once it gets closer to deadline time

This is how we've usually used them in Jupyter projects. It's not that they must block a release, but rather that the the decision to not include a given feature/fix is explicitly rather than simply forgetting, which can happen with longstanding issues. The idea is: we're getting close to release, go through issues tagged with the milestone and ask "Is this really a blocker that we need to tackle, or should we let it slip?" This has worked well for me, but I'm not sure how clear it is or how comfortable other team members might be in deciding what gets punted vs should stick around as a blocker. It works best when we have thorough milestone/tagging coverage of issues, which we have had in the past on some Jupyter repos, but I'm not sure we have now.

[choldgraf]

I'm fine on this as a system - I think the bottleneck will be people having the bandwidth to stay on top of the milestones/tags/etc for a given repository. Any system isn't going to work if we don't have person-time reliably going into maintaining it. :-/ perhaps this is something the "JupyterHub fellow" could help with?

[willingc]

We have a "JupyterHub fellow"???

[davidrpugh]

I was just able to upgrade my Ubuntu 16.04 LTS docker to 19.03 which supports copy-as-user with variable substitution. Hopefully GKE will update the supported Docker version soon!

[choldgraf]

@willingc not yet but maybe (hopefully?) sometime soon :-) jupyterhub/team-compass#165

Was just trying to brainstorm things that this person could do if they began existing!