<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, 2 Jul 2016 at 01:02 Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6/28/2016 4:56 PM, Sean Dague wrote:<br>
> On 06/28/2016 01:46 AM, Angus Lees wrote:<br>
>> Ok, thanks for the in-depth explanation.<br>
>><br>
>> My take away is that we need to file any rootwrap updates as exceptions<br>
>> for now (so releasenotes and grenade scripts).<br>
><br>
> That is definitely the fall back if there is no better idea. However, we<br>
> should try really hard to figure out if there is a non manual way<br>
> through this. Even if that means some compat code that we keep for a<br>
> release to just bridge the gap.<br>
><br>
>     -Sean<br>
><br>
<br>
Walter had this for os-brick:<br>
<br>
<a href="https://review.openstack.org/#/c/329586/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/329586/</a><br>
<br>
That would fallback to rootwrap if privsep doesn't work / not available.<br>
That could be a workaround for upgrading with os-brick for Newton, with<br>
a big fat warning logged if we use it, and then drop it in Ocata and<br>
require privsep.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).  <span style="line-height:1.5">The various privsep-only suggestions about fallback strategies don't help in these other examples.  </span><span style="line-height:1.5">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.</span></div><div><br></div><div> - Gus</div></div></div>