Open Stack

On Tue, Apr 26, 2016 at 10:55 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> 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 :(

Sam Betts

> - 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
>

Thanks for following up Rob.

Related to this, (and not to steer this off on a tangent) is the frequency
of major version changes in libraries, more specifically API breaking
changes.

The items mentioned in this thread would be difficult at best unless we
have stable [backwards compatible] APIs.

-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160427/87d4ef1b/attachment.html>