The python27 packages Ihar has linked do not conflict with the system python 2.6, so I don't see any problems with the rollback here.
Is rollback the only concern for the master node upgrade use case? On Mon, Jan 12, 2015 at 9:51 AM, Evgeniy L <e...@mirantis.com> wrote: > Hi Dmitry, > >>> Client uses REST API to interact with Fuel, how is Python version a >>> factor? > > Fuel client is written in python it means it won't work on the master node > with 2.6 python if you drop compatibility with it. > >>> What exactly is the use cases that requires a new client deployed on an >>> old Fuel master node (or vice versa)? > > Fuel master node upgrade, we install newer client during the upgrade. > >>> It's not that hard ... > > It looks not so hard, but it should be well tested before it's merged, > and it's risky because fuel client is installed on the host system, not > into the container, hence in case if something goes wrong we cannot > make automatic rollback. > > Thanks, > > On Mon, Jan 12, 2015 at 8:24 PM, Dmitry Borodaenko > <dborodae...@mirantis.com> wrote: >> >> On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L <e...@mirantis.com> wrote: >> > Agree with Igor, I think we cannot just drop compatibility for fuel >> > client >> > with 2.6 python, >> >> Hm, didn't Igor say in his email that "we have to drop python 2.6 >> support"? >> >> > the reason is we have old master nodes which have >> > 2.6 python, and the newer fuel client should work fine on these >> > environments. >> >> Client uses REST API to interact with Fuel, how is Python version a >> factor? >> >> What exactly is the use cases that requires a new client deployed on >> an old Fuel master node (or vice versa)? >> >> > Or we can try to install python 2.7 on the master during the upgrade. >> >> Lets do this. It's not that hard, see the link in an email from Ihar >> Hrachyshka on this thread. >> >> > As for Nailgun I don't see any problems to use 2.7. >> > >> > Thanks, >> > >> > On Mon, Jan 12, 2015 at 7:32 PM, Igor Kalnitsky >> > <ikalnit...@mirantis.com> >> > wrote: >> >> >> >> Hi, Roman, >> >> >> >> Indeed, we have to go forward and drop python 2.6 support. That's how >> >> it supposed to be, but, unfortunately, it may not be as easy as it >> >> seems at first glance. >> >> >> >> Fuel Master is flying on top of Cent OS 6.5 which doesn't have python >> >> 2.7 at all. So we must either run master node on Cent OS 7 or build >> >> python2.7 for Cent OS 6.5. The first case, obviously, requires a lot >> >> of work, while the second one is not. But I may wrong, since I have no >> >> idea what dependencies python 2.7 requires and what we have in our >> >> repos. >> >> >> >> - Igor >> >> >> >> On Mon, Jan 12, 2015 at 4:55 PM, Roman Prykhodchenko <m...@romcheg.me> >> >> wrote: >> >> > Folks, >> >> > >> >> > as it was planned and then announced at the OpenStack summit >> >> > OpenStack >> >> > services deprecated Python-2.6 support. At the moment several >> >> > services and >> >> > libraries are already only compatible with Python>=2.7. And there is >> >> > no >> >> > common sense in trying to get back compatibility with Py2.6 because >> >> > OpenStack infra does not run tests for that version of Python. >> >> > >> >> > The point of this email is that some components of Fuel, say, Nailgun >> >> > and Fuel Client are still only tested with Python-2.6. Fuel Client in >> >> > it’s >> >> > turn is about to use OpenStack CI’s python-jobs for running unit >> >> > tests. That >> >> > means that in order to make it compatible with Py2.6 there is a need >> >> > to run >> >> > a separate python job in FuelCI. >> >> > >> >> > However, I believe that forcing the things being compatible with 2.6 >> >> > when the rest of ecosystem decided not to go with it and when Py2.7 >> >> > is >> >> > already available in the main CentOS repo sounds like a battle with >> >> > the >> >> > common sense. So my proposal is to drop 2.6 support in Fuel-6.1. >> >> > >> >> > >> >> > - romcheg >> >> > >> >> > >> >> > >> >> > __________________________________________________________________________ >> >> > 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 >> > >> > >> > >> > >> > __________________________________________________________________________ >> > 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 >> > >> >> >> >> -- >> Dmitry Borodaenko >> >> __________________________________________________________________________ >> 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 > -- Dmitry Borodaenko __________________________________________________________________________ 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
