Open Stack

On 26 April 2016 at 18:41, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
>
>> On Apr 26, 2016, at 6:32 PM, Perry, Sean <sean.perry at hpe.com> wrote:
>>
>> What if we update the docs and tell people to put any services on a shared system into independent virtualenvs?
>>
>> If a box only runs neutron or whatever all is well. The issue happens when you mix and match services on a single host. Which is exactly what virtualenv was intended to fix.
>
> Except that a fair portion of respondents to the OpenStack User Survey talk about using packages provided by the distribution of Linux they happen to be on. Those cannot be installed into virtual environments.

Right. The specific situation is 'same python environment' - so distro
packages all land in the same python environment. You can make
packages of virtualenvs and other such things - and folk wanting to be
able to do same-node-no-container-distro-package in-place upgrade
solutions would be looking at such things if we decide we don't want
to support/enable this.

Some distros were in the room, and e.g. I believe it was Dan that said
RH don't support - in their packaging - mixed versions: upgrade nova,
and neutron would be upgraded too in the given example. So its
possible that while some folk aspire to it, many other folk are either
accepting downtime, or running their control plane on isolated
operating system instances (whether physical, VM or containers is
irrelevant).

At the party tonight I ran into Brian Demers and a colleague whose
name I have forgotten :( - but they have a backwards compat use case
we hadn't touched on in the session: running their Neutron plugin
against both stable and master of Neutron.

This is a classic colocation situation. There are a few possible scenarios:
 - run stable branches of the plugin and backport everything
    - tricky if new oslo features are needed, but the existing pattern.
    - also tricky for users, since there would be lots of releases of
both stable and master
 - run master against stable neutron using stable neutron oslo
     - means they can't use any new oslo features, and they would
depend on oslo not breaking any API's they use in master - so depends
on oslo API compat
     - or they have to provide backports within their tree and monkey
patch them into place, of new/changed things from oslo
 - run master against stable neutron using master oslo
    - means neutron would have to work with master oslo - so the same
compat story, just from the other side


(Clearly there are also Neutron API driver things to discuss, but this
is in the context of the libraries thread :)).

I wonder how many other folk are trying to attempt such a thing -
anyone care to raise their metaphorical hand?

-Rob


-- 
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud