On Thu, Aug 2, 2018 at 12:45 PM, Clark Boylan <cboy...@sapwetik.org> wrote: > On Thu, Aug 2, 2018, at 9:57 AM, Alex Schultz wrote: >> Ahoy infra folks, >> >> So TripleO/RDO is currently working on our transition from python2 to >> python3 and would like to stabilize on Fedora 28 during the Stein >> cycle until a newer version of CentOS comes out with proper python3 >> support. So we would like to ask if it would be possible to keep >> Fedora 28 around until Fedora 30 comes out + 1 month. This is the >> published maintenance schedule[0]. Based on current assumptions this >> would mean that Fedora 28 would be EOL around June, 2019. Ideally our >> plan would be to migrate off of the Fedora 28 jobs before it is >> officially EOL. >> >> We are aware that release schedules can change and are definitely >> keeping an eye on that in terms of Fedora. The next release of Fedora >> 29 is slated to include python 3.7 which may be too new for >> OpenStack[1] so we would like to start work on the 3.6 that is >> available from 28. We've already started working on getting packaging >> working for Fedora 28. Our first goal is to get the various services >> and deployments working under 3.6. Once that has been tackled, an >> upgrade to Fedora 29 or newer will likely be less work than trying to >> go from 2.7 to 3.7. >> >> We would like to use fedora 28 rather than something like python3 from >> EPEL7 in that it would be a better representation of a Red Hat based >> OS without any python2 support. We're looking to uncover the python 2 >> to 3 transition issues with TripleO as well as starting to pull in >> other newer dependencies. >> >> Thanks, >> -Alex >> >> [0] >> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-July/132179.html > > The main reason for wanting to move up the list of Fedora releases quickly > was the people supporting the Fedora images didn't want to invest in older > releases once they were superseded. If tripleo (or others) are willing to > help care for those images and fix them when they break, we should be able to > support them through the entirety of their designated lifetime. I do not > expect we would keep images around for releases that have reached their end > of life. It just isn't practical to try and keep up with security issues, and > we should move on. >
Yes we would assist in addressing breakages as necessary and also agree about not keeping them past EOL. We'll probably end up targeting having some sort of basic gate job during stein so we'll be very aware of breakages. > Considering that, I think we can hold off removing Fedora 28 images until > that release's EOL date or if they break for a prolonged period of time with > no one working to fix it. > > As a note, Fedora 28 does come with python2.7. It is installed so that Zuul > related ansible things can execute under python2 on the test nodes. There is > the possibility that ansible's python3 support is working well enough that we > could switch to it, but that requires testing and updates to software and > images and config. > Hmm ok, we'll have to make sure that doesn't conflict. Good to know. Thanks, -Alex > Hope this helps, > Clark > > > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
