Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:31:34AM -0500, Monty Taylor wrote: > there is also > > https://review.openstack.org/#/c/580730/ > > which adds a role to install docker and configure it to use the correct > registry. shiny! That'll take care of all the docker setup nice! Can I create a job that Depends-On that one and see what happens when I try to build/run containers? /me suspects so but sometimes I like to check :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:05:09AM -0500, Matthew Thode wrote: > I'm of the opinion that we should decouple from distro supported python > versions and rely on what versions upstream python supports (longer > lifetimes than our releases iirc). Using docker/pyenv does this decoupling but I'm not convinced that any option really means that we dont' end up running something that's EOL somewhere. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:31:34AM -0500, Monty Taylor wrote: > FWIW, I use pyenv for python versions on my laptop and love it. I've > completely given up on distro-provided python for my own usage. Hmm okay I'll look at that and how it'd play with the generate job. It's quite possible I'm being short sighted but I'd really like to *not* have to build anything. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 01:52:56PM +, Jeremy Stanley wrote: > On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: > [...] > > I think most of the problems with Fedora stability are around > > bringing up a new Fedora every 6 months or so. They tend to change > > sufficiently within that time period to make this a fairly > > involved exercise. But once working they work for the ~13 months > > of support they offer. I know Paul Belanger would like to iterate > > more quickly and just keep the most recent Fedora available > > (rather than ~2). > [...] > > Regardless its instability/churn makes it unsuitable for stable > branch jobs because the support lifetime of the distro release is > shorter than the maintenance lifetime of our stable branches. Would > probably be fine for master branch jobs but not beyond, right? Yup we only run the generate job on master, once we branch it's up to poeple to update/review the lists. So I'd hope that we'd have f28 and f29 overlap and roll forward as needed/able Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 06:37:52AM -0700, Clark Boylan wrote: > On Wed, Jul 11, 2018, at 9:34 PM, Tony Breeds wrote: > > 1. Build pythons from source and use that to construct the venv > >[please no] > > Fungi mentions that 3.3 and 3.4 don't build easily on modern linux distros. > However, 3.3 and 3.4 are also unsupported by Python at this point, maybe we > can ignore them and focus on 3.5 and forward? We don't build new freeze lists > for the stable branches, this is just a concern for master right? The focus is master, but it came up in the context of shoudl we just remove the python_version=='3.4', it turns out that at least one OS that will supported rock will be running with python 3.4 so while 3.4 is EOL I have to admit I'd quite like to be able to keep the 3.4 stuff around for rocky (and probably stein). It isn't a hard requirement. > > 2. Generate the constraints in an F28 image. My F28 has ample python > >versions: > > - /usr/bin/python2.6 > > - /usr/bin/python2.7 > > - /usr/bin/python3.3 > > - /usr/bin/python3.4 > > - /usr/bin/python3.5 > > - /usr/bin/python3.6 > > - /usr/bin/python3.7 > >I don't know how valid this still is but in the past fedora images > >have been seen as unstable and hard to keep current. If that isn't > >still the feeling then we could go down this path. Currently there a > >few minor problems with bindep.txt on fedora and generate-constraints > >doesn't work with py3 but these are pretty minor really. > > I think most of the problems with Fedora stability are around bringing up a > new Fedora every 6 months or so. They tend to change sufficiently within that > time period to make this a fairly involved exercise. But once working they > work for the ~13 months of support they offer. I know Paul Belanger would > like to iterate more quickly and just keep the most recent Fedora available > (rather than ~2). Ok that's good context. It isn't that once the images are built they break it that they're hardish to build in the first place. I'd love to think that between Paul, Ian and I we'd be okay here but then again I don't really know what I'm saying ;P > > 3. Use docker images for python and generate the constraints with > >them. I've hacked up something we could use as a base for that in: > > https://review.openstack.org/581948 > > > >There are lots of open questions: > > - How do we make this nodepool/cloud provider friendly ? > >* Currently the containers just talk to the main debian mirrors. > > Do we have debian packages? If so we could just do sed magic. > > http://$MIRROR/debian (http://mirror.dfw.rax.openstack.org/debian for > example) should be a working amd64 debian package mirror. \o/ > > - Do/Can we run a registry per provider? > > We do not, but we do have a caching dockerhub registry proxy in each > region/provider. http://$MIRROR:8081/registry-1.docker if using older docker > and http://$MIRROR:8082 for current docker. This was a compromise between > caching the Internet and reliability. That'll do as long as it's easy to configure or transparent. > > - Can we generate and caches these images and only run pip install -U > >g-r to speed up the build > > Between cached upstream python docker images and prebuilt wheels mirrored in > every cloud provider region I wonder if this will save a significant amount > of time? May be worth starting without this and working from there if it > remains slow. Yeah it may be that I'm over thinking it. For me (locally) it's really slow but perhaps with infrastructure you've mentioned it isn't worth it. Certainly something to look at later if it's a problem. > > - Are we okay with using docker this way? > > Should be fine, particularly if we are consuming the official Python images. Yup that's the plan. I've sent a PR to get some images we'd need built that aren't there today. > > > > > I like #2 the most but I wanted to seek wider feedback. > > I think each proposed option should work as long as we understand the > limitations each presents. #2 should work fine if we have individuals > interested and able to spin up new Fedora images and migrate jobs to that > image after releases happen. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On 07/12/2018 11:05 AM, Matthew Thode wrote: On 18-07-12 13:52:56, Jeremy Stanley wrote: On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: [...] I think most of the problems with Fedora stability are around bringing up a new Fedora every 6 months or so. They tend to change sufficiently within that time period to make this a fairly involved exercise. But once working they work for the ~13 months of support they offer. I know Paul Belanger would like to iterate more quickly and just keep the most recent Fedora available (rather than ~2). [...] Regardless its instability/churn makes it unsuitable for stable branch jobs because the support lifetime of the distro release is shorter than the maintenance lifetime of our stable branches. Would probably be fine for master branch jobs but not beyond, right? I'm of the opinion that we should decouple from distro supported python versions and rely on what versions upstream python supports (longer lifetimes than our releases iirc). Yeah. I don't want to boil the ocean too much ... but as I mentioned in my other reply, I'm very pleased with pyenv. I would not be opposed to switching to that for all of our python installation needs. OTOH, I'm not going to push for it, nor do I have time to implement such a switch. But I'd vote for it and cheer someone on if they did. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On 07/12/2018 08:37 AM, Clark Boylan wrote: On Wed, Jul 11, 2018, at 9:34 PM, Tony Breeds wrote: Hi Folks, We have a pit of a problem in openstack/requirements and I'd liek to chat about it. Currently when we generate constraints we create a venv for each (system) python supplied on the command line, install all of global-requirements into that venv and capture the pip freeze. Where this falls down is if we want to generate a freeze for python 3.4 and 3.5 we need an image that has both of those. We cheated and just 'clone' them so if python3 is 3.4 we copy the results to 3.5 and vice versa. This kinda worked for a while but it has drawbacks. I can see a few of options: 1. Build pythons from source and use that to construct the venv [please no] Fungi mentions that 3.3 and 3.4 don't build easily on modern linux distros. However, 3.3 and 3.4 are also unsupported by Python at this point, maybe we can ignore them and focus on 3.5 and forward? We don't build new freeze lists for the stable branches, this is just a concern for master right? FWIW, I use pyenv for python versions on my laptop and love it. I've completely given up on distro-provided python for my own usage. 2. Generate the constraints in an F28 image. My F28 has ample python versions: - /usr/bin/python2.6 - /usr/bin/python2.7 - /usr/bin/python3.3 - /usr/bin/python3.4 - /usr/bin/python3.5 - /usr/bin/python3.6 - /usr/bin/python3.7 I don't know how valid this still is but in the past fedora images have been seen as unstable and hard to keep current. If that isn't still the feeling then we could go down this path. Currently there a few minor problems with bindep.txt on fedora and generate-constraints doesn't work with py3 but these are pretty minor really. I think most of the problems with Fedora stability are around bringing up a new Fedora every 6 months or so. They tend to change sufficiently within that time period to make this a fairly involved exercise. But once working they work for the ~13 months of support they offer. I know Paul Belanger would like to iterate more quickly and just keep the most recent Fedora available (rather than ~2). 3. Use docker images for python and generate the constraints with them. I've hacked up something we could use as a base for that in: https://review.openstack.org/581948 There are lots of open questions: - How do we make this nodepool/cloud provider friendly ? * Currently the containers just talk to the main debian mirrors. Do we have debian packages? If so we could just do sed magic. http://$MIRROR/debian (http://mirror.dfw.rax.openstack.org/debian for example) should be a working amd64 debian package mirror. - Do/Can we run a registry per provider? We do not, but we do have a caching dockerhub registry proxy in each region/provider. http://$MIRROR:8081/registry-1.docker if using older docker and http://$MIRROR:8082 for current docker. This was a compromise between caching the Internet and reliability. there is also https://review.openstack.org/#/c/580730/ which adds a role to install docker and configure it to use the correct registry. - Can we generate and caches these images and only run pip install -U g-r to speed up the build Between cached upstream python docker images and prebuilt wheels mirrored in every cloud provider region I wonder if this will save a significant amount of time? May be worth starting without this and working from there if it remains slow. - Are we okay with using docker this way? Should be fine, particularly if we are consuming the official Python images. Agree. python:3.6 and friends are great. I like #2 the most but I wanted to seek wider feedback. I think each proposed option should work as long as we understand the limitations each presents. #2 should work fine if we have individuals interested and able to spin up new Fedora images and migrate jobs to that image after releases happen. Clark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On 18-07-12 13:52:56, Jeremy Stanley wrote: > On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: > [...] > > I think most of the problems with Fedora stability are around > > bringing up a new Fedora every 6 months or so. They tend to change > > sufficiently within that time period to make this a fairly > > involved exercise. But once working they work for the ~13 months > > of support they offer. I know Paul Belanger would like to iterate > > more quickly and just keep the most recent Fedora available > > (rather than ~2). > [...] > > Regardless its instability/churn makes it unsuitable for stable > branch jobs because the support lifetime of the distro release is > shorter than the maintenance lifetime of our stable branches. Would > probably be fine for master branch jobs but not beyond, right? I'm of the opinion that we should decouple from distro supported python versions and rely on what versions upstream python supports (longer lifetimes than our releases iirc). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: [...] > I think most of the problems with Fedora stability are around > bringing up a new Fedora every 6 months or so. They tend to change > sufficiently within that time period to make this a fairly > involved exercise. But once working they work for the ~13 months > of support they offer. I know Paul Belanger would like to iterate > more quickly and just keep the most recent Fedora available > (rather than ~2). [...] Regardless its instability/churn makes it unsuitable for stable branch jobs because the support lifetime of the distro release is shorter than the maintenance lifetime of our stable branches. Would probably be fine for master branch jobs but not beyond, right? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Wed, Jul 11, 2018, at 9:34 PM, Tony Breeds wrote: > Hi Folks, > We have a pit of a problem in openstack/requirements and I'd liek to > chat about it. > > Currently when we generate constraints we create a venv for each > (system) python supplied on the command line, install all of > global-requirements into that venv and capture the pip freeze. > > Where this falls down is if we want to generate a freeze for python 3.4 > and 3.5 we need an image that has both of those. We cheated and just > 'clone' them so if python3 is 3.4 we copy the results to 3.5 and vice > versa. This kinda worked for a while but it has drawbacks. > > I can see a few of options: > > 1. Build pythons from source and use that to construct the venv >[please no] Fungi mentions that 3.3 and 3.4 don't build easily on modern linux distros. However, 3.3 and 3.4 are also unsupported by Python at this point, maybe we can ignore them and focus on 3.5 and forward? We don't build new freeze lists for the stable branches, this is just a concern for master right? > > 2. Generate the constraints in an F28 image. My F28 has ample python >versions: > - /usr/bin/python2.6 > - /usr/bin/python2.7 > - /usr/bin/python3.3 > - /usr/bin/python3.4 > - /usr/bin/python3.5 > - /usr/bin/python3.6 > - /usr/bin/python3.7 >I don't know how valid this still is but in the past fedora images >have been seen as unstable and hard to keep current. If that isn't >still the feeling then we could go down this path. Currently there a >few minor problems with bindep.txt on fedora and generate-constraints >doesn't work with py3 but these are pretty minor really. I think most of the problems with Fedora stability are around bringing up a new Fedora every 6 months or so. They tend to change sufficiently within that time period to make this a fairly involved exercise. But once working they work for the ~13 months of support they offer. I know Paul Belanger would like to iterate more quickly and just keep the most recent Fedora available (rather than ~2). > > 3. Use docker images for python and generate the constraints with >them. I've hacked up something we could use as a base for that in: > https://review.openstack.org/581948 > >There are lots of open questions: > - How do we make this nodepool/cloud provider friendly ? >* Currently the containers just talk to the main debian mirrors. > Do we have debian packages? If so we could just do sed magic. http://$MIRROR/debian (http://mirror.dfw.rax.openstack.org/debian for example) should be a working amd64 debian package mirror. > - Do/Can we run a registry per provider? We do not, but we do have a caching dockerhub registry proxy in each region/provider. http://$MIRROR:8081/registry-1.docker if using older docker and http://$MIRROR:8082 for current docker. This was a compromise between caching the Internet and reliability. > - Can we generate and caches these images and only run pip install -U >g-r to speed up the build Between cached upstream python docker images and prebuilt wheels mirrored in every cloud provider region I wonder if this will save a significant amount of time? May be worth starting without this and working from there if it remains slow. > - Are we okay with using docker this way? Should be fine, particularly if we are consuming the official Python images. > > I like #2 the most but I wanted to seek wider feedback. I think each proposed option should work as long as we understand the limitations each presents. #2 should work fine if we have individuals interested and able to spin up new Fedora images and migrate jobs to that image after releases happen. Clark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
