Open Stack

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 <eli at 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
> <dborodaenko at mirantis.com> wrote:
>>
>> On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L <eli at 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
>> > <ikalnitsky at 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 <me at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dmitry Borodaenko