<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 24 Jun 2016 at 21:04 Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/24/2016 05:19 AM, Daniel P. Berrange wrote:<br>
> On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:<br>
>> No perfect answer here... I'm hesitating between (0), (1) and (4). (4) is<br>
>> IMHO the right solution, but it's a larger change for downstream. (1) is a<br>
>> bit of a hack, where we basically hardcode in rootwrap that it's being<br>
>> transitioned to privsep. That's fine, but only if we get rid of rootwrap<br>
>> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a<br>
>> hard sell for upgrade procedures -- if we need to take a hit in that area,<br>
>> let's do (4) directly...<br>
>><br>
>> In summary, I think the choice is between (1)+(4) and doing (4) directly.<br>
>> How doable is (4) in the timeframe we have ? Do we all agree that (4) is the<br>
>> endgame ?<br>
><br>
> We've already merged change to privsep to allow nova/cinder/etc to<br>
> initialize the default helper command to use rootwrap:<br>
><br>
>   <a href="https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487</a><br>
><br>
> So we just need new release of privsep & add code to nova to initialize<br>
> it and we're sorted.<br>
<br>
Actually, I don't think so. Matt ran that test scenario, and we're<br>
missing the rootwrap rule that lets privsep-helper run as root. So we<br>
fail to start the daemon from the unpriv nova compute process post upgrade.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 :-)</div><div><br></div><div> - Gus</div></div></div>