[openstack-dev] [grenade] upgrades vs rootwrap

Angus Lees gus at inodes.org
Fri Jun 24 12:19:45 UTC 2016

On Fri, 24 Jun 2016 at 21:04 Sean Dague <sean at dague.net> wrote:

> On 06/24/2016 05:19 AM, Daniel P. Berrange wrote:
> > On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:
> >> No perfect answer here... I'm hesitating between (0), (1) and (4). (4)
> is
> >> IMHO the right solution, but it's a larger change for downstream. (1)
> is a
> >> bit of a hack, where we basically hardcode in rootwrap that it's being
> >> transitioned to privsep. That's fine, but only if we get rid of rootwrap
> >> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a
> >> hard sell for upgrade procedures -- if we need to take a hit in that
> area,
> >> let's do (4) directly...
> >>
> >> In summary, I think the choice is between (1)+(4) and doing (4)
> directly.
> >> How doable is (4) in the timeframe we have ? Do we all agree that (4)
> is the
> >> endgame ?
> >
> > We've already merged change to privsep to allow nova/cinder/etc to
> > initialize the default helper command to use rootwrap:
> >
> >
> https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487
> >
> > So we just need new release of privsep & add code to nova to initialize
> > it and we're sorted.
> Actually, I don't think so. Matt ran that test scenario, and we're
> missing the rootwrap rule that lets privsep-helper run as root. So we
> fail to start the daemon from the unpriv nova compute process post upgrade.

Right, I thought that recent privsep change would address this, but we're
having this conversation because it turns out that simply updating code
only is not sufficient.  I (and I presume all the other members of the
earlier review/email discussion) had just assumed that we already had a
sensible process for making orderly changes to rootwrap files.

As I've since learned however, the current openstack upgrade process
doesn't talk about updating the rootwrap files, ever.  The only reason
we've been able to make reasonable progress since this was instituted is
either through the grenade exception mechanism, or by slipping things
through in drivers that are not tested by grenade.  Hence me opening this
fun can of worms for broader discussion in this thread.  You're welcome :-)

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160624/6ac20394/attachment.html>

More information about the OpenStack-dev mailing list