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

Add stretch variant #465

Merged
merged 7 commits into from
Jul 25, 2017
Merged

Add stretch variant #465

merged 7 commits into from
Jul 25, 2017

Conversation

chorrell
Copy link
Contributor

@chorrell chorrell commented Jul 13, 2017

This is the first step to transitioning over to Debian Stretch (9) for the base images.

The yarn versions should match up with what we currently have set for a given Node.js version, but it would be great if someone could sanity check that for me :)

Also note that full support for Jessie will drop around June 2018. That might be the right timing for a transition or at least something to consider

This is the first step to transitioning over to stretch for the base
images
pesho

This comment was marked as off-topic.

@pesho
Copy link
Contributor

pesho commented Jul 14, 2017

This is the first step to transitioning over to Debian Stretch (9) for the base images.

What should the next steps look like? Do we switch the default for all versions at some point, or do we need a way to switch the default separately for the different release branches?

SimenB

This comment was marked as off-topic.

@chorrell
Copy link
Contributor Author

I'm still thinking about next steps. I guess, in terms of deadline, we'll need to switch to stretch either by the EOL date for full support (~June 6th 2018) or the EOL date for LTS support (~June 6th 2020):

https://wiki.debian.org/DebianReleases#Production_Releases

I lean more towards going with the full support EOL date. My interpretation of how Debian does LTS is that it's not "real" LTS since it's volunteer based and things might be looser in terms of security updates. I'm probably wrong on that but I find the distinction and their use of "LTS" a bit confusing.

It would be good to know what the plan is for all the other Official Docker images that are Debian based. If all the official images are going to switch to stretch at some point it would be good to coordinate.

For the docker-node image, I would prefer to switch the default for all versions rather than having a mix of jessie and stretch. In practical terms I think we should do the switch when we update Node so people can roll back or pin if they have to.

Also it just occurred to me that we will probably want to create a jessie variant as well to help with the transition. How long we keep that around will also depend on which EOL date we to stick to.

@yosifkit
Copy link
Contributor

@chorrell, we are starting an effort to label all our images with the appropriate OS release: (alpine3.6, wheezy, jessie, stretch, etc., see docker-library/golang#170).

We have not figured out a general solution for changing the default from jessie to stretch (or alpine 3.5 to 3.6). I know for golang we are making the next release, 1.9, default to stretch with no option of jessie (1.7 has wheezy & jessie, while 1.8 offers jessie & stretch). Some of our images may be like golang where we slowly migrate with new releases, others we may have to set either a date or version bump that will be the last jessie as default and then a second date for a final jessie release.

@SimenB
Copy link
Member

SimenB commented Jul 22, 2017

Any reason not to merge this? Switching defaults can be done later, right?
FWIW I agree on just switching default for the next node version release for each of them so that people can pin. Maybe in a minor though, so they still get patch updates?

Can you update with the changes necessary after merging #452? Also move 8.1 to 8.2

@chorrell
Copy link
Contributor Author

Update for 8.2.1.

@SimenB
Copy link
Member

SimenB commented Jul 22, 2017

Stretch is just amd64? (I have no idea, just asking)

@SimenB
Copy link
Member

SimenB commented Jul 22, 2017

Never mind, you just didn't generate new ones after updating the template 😄 That's what I get for being eager.

@chorrell
Copy link
Contributor Author

Right, the arch updates haven't really landed in the docker files yet, just the templates.

@chorrell
Copy link
Contributor Author

So, do I need to modify the architectures file to include stretch?

bashbrew-arch   variants
x64     alpine,onbuild,slim,stretch,wheezy
ppc64le onbuild,slim

@SimenB
Copy link
Member

SimenB commented Jul 22, 2017

@yhwang ^

Starefossen

This comment was marked as off-topic.

yhwang

This comment was marked as off-topic.

yhwang

This comment was marked as off-topic.

@yhwang
Copy link
Member

yhwang commented Jul 24, 2017

oh, in a recent change, I changed x64 to amd64. so the conflict in architectures is easy to fix.

SimenB

This comment was marked as off-topic.

@SimenB
Copy link
Member

SimenB commented Jul 25, 2017

After merging this (and updating the dockerfiles), are we ready for a PR to docker hub with ppc64le and stretch?

@yhwang
Copy link
Member

yhwang commented Jul 25, 2017

@SimenB I am thinking if we could also put stretch into ppc64le. I am going to verify that today based on @chorrell 's change in a ppc64le machine. If it works, could we add stretch also into ppc64le and have a PR for docker hub?

@SimenB
Copy link
Member

SimenB commented Jul 25, 2017

@yhwang, sounds good to me!

@yhwang
Copy link
Member

yhwang commented Jul 25, 2017

Thanks @SimenB . I used @chorrell 's stretch-variant branch and ran the test-build.sh in a ppc64le server for 4.8, 6.11, 7.10 and 8.2. All of the Dockerfiles worked perfectly.

@chorrell since you are the author for the stretch variant (I just verified it on ppc64le for you), do you want to add stretch into ppc64le in file : architectures? or you want me to do that? I am fine with both :-) .

@chorrell
Copy link
Contributor Author

Done.

@SimenB
Copy link
Member

SimenB commented Jul 25, 2017

Red CI is fixed on master. Any reason not to merge this?

@chorrell
Copy link
Contributor Author

Sounds good to me.

@SimenB SimenB merged commit 09e784b into nodejs:master Jul 25, 2017
@SimenB
Copy link
Member

SimenB commented Jul 25, 2017

Are we ready for docker hub pr with stretch and new arch?

@chorrell
Copy link
Contributor Author

Stretch: yes I think so

New arch: not sure.

If upstream/Docker is good us adding the new arch stuff then I guess that's fine.

@yhwang
Copy link
Member

yhwang commented Jul 25, 2017

In node download, the binary files for different architectures are already there. I think it's also good to support multiple architectures for docker user.

One question about the process:

  • who will build the docker images?
    Because building some specific architecture images may need specific server. Do we need to build the images or someone else?

@SimenB
Copy link
Member

SimenB commented Jul 25, 2017

It's the infra of docker that builds, we just point them to the dockerfiles (with the stackbrew diff)

@yhwang
Copy link
Member

yhwang commented Jul 25, 2017

thanks @SimenB . understood! Then no need to worry about the servers. great!

@victornoel
Copy link

@SimenB do you have an ETA of when it will be available on docker hub? :)

@SimenB
Copy link
Member

SimenB commented Jul 26, 2017

@SimenB
Copy link
Member

SimenB commented Jul 26, 2017

@victornoel It's available now

@victornoel
Copy link

@SimenB thanks for notifying and for the link, I didn't understand the process actually, now I know :)

@victornoel
Copy link

@SimenB actually, that's strange, even though the stretch variant is present in ppc64le (https://hub.docker.com/r/ppc64le/node/), the amd64 one is not up to date…

@cebor
Copy link

cebor commented Jul 27, 2017

Is there a schedule when stretch will be the default image for node?

@chorrell
Copy link
Contributor Author

No not yet.

@SimenB
Copy link
Member

SimenB commented Jul 27, 2017

@victornoel stretch is here: https://hub.docker.com/_/node/

@victornoel
Copy link

@SimenB that's my point, if you look at the tag list: https://hub.docker.com/r/library/node/tags/

it is not there, the last push is from a day ago while the PR was merged half a day ago.

@SimenB
Copy link
Member

SimenB commented Jul 27, 2017

Ah! And docker pull doesn't work?

@victornoel
Copy link

@SimenB
Copy link
Member

SimenB commented Jul 27, 2017

@tianon ^ ideas?

@tianon
Copy link
Contributor

tianon commented Jul 27, 2017

There was a hiccup or two in building/pushing, but all artifacts should be (long-since) up now:

$ docker pull node:stretch
stretch: Pulling from library/node
Digest: sha256:2afc089d9902461f94df2c44e2595a4625c3994a4b18f305703ba9607e09886d
Status: Image is up to date for node:stretch

$ docker pull ppc64le/node:stretch
stretch: Pulling from ppc64le/node
Digest: sha256:f6cb450cc56f264e313d00874cef2e6e2d4c765a3606ac3499ef560816e77544
Status: Image is up to date for ppc64le/node:stretch

@SimenB
Copy link
Member

SimenB commented Jul 28, 2017

They're also here: https://hub.docker.com/r/library/node/tags/

Thanks!

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.

None yet

9 participants