<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 10:55 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26 April 2016 at 18:41, Ian Cordasco <<a href="mailto:sigmavirus24@gmail.com">sigmavirus24@gmail.com</a>> wrote:<br>
><br>
>> On Apr 26, 2016, at 6:32 PM, Perry, Sean <<a href="mailto:sean.perry@hpe.com">sean.perry@hpe.com</a>> wrote:<br>
>><br>
>> What if we update the docs and tell people to put any services on a shared system into independent virtualenvs?<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
<br>
</span>Right. The specific situation is 'same python environment' - so distro<br>
packages all land in the same python environment. You can make<br>
packages of virtualenvs and other such things - and folk wanting to be<br>
able to do same-node-no-container-distro-package in-place upgrade<br>
solutions would be looking at such things if we decide we don't want<br>
to support/enable this.<br>
<br>
Some distros were in the room, and e.g. I believe it was Dan that said<br>
RH don't support - in their packaging - mixed versions: upgrade nova,<br>
and neutron would be upgraded too in the given example. So its<br>
possible that while some folk aspire to it, many other folk are either<br>
accepting downtime, or running their control plane on isolated<br>
operating system instances (whether physical, VM or containers is<br>
irrelevant).<br>
<br>
At the party tonight I ran into Brian Demers and a colleague whose<br>
name I have forgotten :( </blockquote><div>Sam Betts</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- but they have a backwards compat use case<br>
we hadn't touched on in the session: running their Neutron plugin<br>
against both stable and master of Neutron.<br>
<br>
This is a classic colocation situation. There are a few possible scenarios:<br>
 - run stable branches of the plugin and backport everything<br>
    - tricky if new oslo features are needed, but the existing pattern.<br>
    - also tricky for users, since there would be lots of releases of<br>
both stable and master<br>
 - run master against stable neutron using stable neutron oslo<br>
     - means they can't use any new oslo features, and they would<br>
depend on oslo not breaking any API's they use in master - so depends<br>
on oslo API compat<br>
     - or they have to provide backports within their tree and monkey<br>
patch them into place, of new/changed things from oslo<br>
 - run master against stable neutron using master oslo<br>
    - means neutron would have to work with master oslo - so the same<br>
compat story, just from the other side<br>
</blockquote><div><br></div><div>Thanks for following up Rob.</div><div><br></div><div>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.  </div><div><br></div><div>The items mentioned in this thread would be difficult at best unless we have stable [backwards compatible] APIs. </div><div><br></div><div>-Brian</div><div><br></div><div><br></div></div></div></div>