[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

Matt Riedemann mriedem at linux.vnet.ibm.com
Fri Jul 22 14:54:21 UTC 2016


On 7/22/2016 8:20 AM, Angus Lees wrote:
> On Thu, 21 Jul 2016 at 09:27 Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
>
>     On 07/12/2016 06:25 AM, Matt Riedemann wrote:
>     <snip>
>     > We probably aren't doing anything while Sean Dague is on vacation.
>     He's
>     > back next week and we have the nova/cinder meetups, so I'm planning on
>     > talking about the grenade issue in person and hopefully we'll have a
>     > plan by the end of next week to move forward.
>
>     After some discussions at the Nova midcycle we threw together an
>     approach where we just always allow privsep-helper from oslo.rootwrap.
>
>     https://review.openstack.org/344450
>
>
> Were these discussions captured anywhere?  I thought we'd discussed
> alternatives on os-dev, reached a conclusion, implemented the
> changes(*), and verified the results all a month ago - and that we were
> just awaiting nova approval.  So I'm surprised to see this sudden change
> in direction...
>
> (*) Changes:
> https://review.openstack.org/#/c/329769/
> https://review.openstack.org/#/c/332610/
> mriedem's verification: https://review.openstack.org/#/c/331885/
>
>  - Gus
>
>     We did a sniff test of this, and it worked to roll over the upgrade
>     boundary, without an etc change, and work with osbrick 1.4.0 (currently
>     blacklisted because of the upgrade issue). While I realize it wasn't the
>     favorite approach by many it works. It's 3 lines of functional change.
>     If we land this, release, and bump the minimum, we've got the upgrade
>     issue solved in this cycle.
>
>     Please take a look and see if we can agree to this path forward.
>
>             -Sean
>
>     --
>     Sean Dague
>     http://dague.net
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     --
>     Message  protected by MailGuard: e-mail anti-virus, anti-spam and
>     content filtering.http://www.mailguard.com.au/mg
>     Click here to report this message as spam:
>     https://console.mailguard.com.au/ras/1OSGOh3pqW/kb4I7l49SLBdqHGpZpoHi/0.82
>
>
>
> __________________________________________________________________________
> 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
>

We talked about it at the nova midcycle, the etherpad is here but the 
notes on privsep/grenade are pretty sparse:

https://etherpad.openstack.org/p/nova-newton-midcycle

Long-term we want this in code, which is why privsep is for, but today 
it's config because it's deployed into /etc, so we treat it as config 
with the same rules for upgrades that are applied in grenade for actual 
config options, i.e. new code should be able to run on old config.

I mentioned that we still break this for other new filters which we 
don't test, but the feeling was we shouldn't change how we do this for 
things we do test since operators rely on it and upgrade is their top 
pain point.

We also decided that simply hard-coding the privsep-helper in 
oslo.rootwrap itself was better than needing to script/hack the same 
thing for every project that is going to adopt privsep - and we can 
isolate it in the rootwrap library so there are no exceptional upgrade 
scripts for newton (for nova, or anyone).

So this is not great, but it's the least bad to get us over this issue 
for newton and unblock os-brick and os-vif and allow new projects to 
start adopting privsep and not hit the same upgrade issues.

mikal suggested that gus and sdague talk over a hangout or some higher 
bandwidth medium if we still need to hash things out here.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list