[openstack-dev] [grenade] upgrades vs rootwrap

Angus Lees gus at inodes.org
Mon Jul 4 03:25:06 UTC 2016


On Sat, 2 Jul 2016 at 01:02 Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> On 6/28/2016 4:56 PM, Sean Dague wrote:
> > On 06/28/2016 01:46 AM, Angus Lees wrote:
> >> Ok, thanks for the in-depth explanation.
> >>
> >> My take away is that we need to file any rootwrap updates as exceptions
> >> for now (so releasenotes and grenade scripts).
> >
> > That is definitely the fall back if there is no better idea. However, we
> > should try really hard to figure out if there is a non manual way
> > through this. Even if that means some compat code that we keep for a
> > release to just bridge the gap.
> >
> >     -Sean
> >
>
> Walter had this for os-brick:
>
> https://review.openstack.org/#/c/329586/
>
> That would fallback to rootwrap if privsep doesn't work / not available.
> That could be a workaround for upgrading with os-brick for Newton, with
> a big fat warning logged if we use it, and then drop it in Ocata and
> require privsep.
>

Yes, this is basically a version of "submit the rootwrap filter, then wait
6 months before submitting the code that needs it".   If we don't wish to
use the exception mechanism (or adjust the policy to upgrade conf before
code as I described earlier), then we can certainly do this.  Rather than
log a big fat warning if we use privsep, we may as well just revert the
privsep change for os-brick and then resubmit it next cycle.

This thread topic isn't actually about privsep however, although a
migration to privsep will mostly mitigate this in the future which is
perhaps why it is causing topic collisions for everyone.

I see there are already a few other additions to the rootwrap filters in
nova/cinder (the comments suggest (nova) libvirt/imagebackend.py, (cinder)
remotefs.py, and (both) vzstorage.py).  The various privsep-only
suggestions about fallback strategies don't help in these other examples.  Any
corresponding code changes that rely on these new filters will also need to
be reverted and resubmitted during next cycle - or do what usually happens
and slip under the radar as they are not exercised by grenade.

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


More information about the OpenStack-dev mailing list