[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