[openstack-dev] [grenade] upgrades vs rootwrap

Angus Lees gus at inodes.org
Mon Jun 27 02:47:55 UTC 2016


On Fri, 24 Jun 2016 at 19:13 Thierry Carrez <thierry at openstack.org> wrote:

> 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 ?
>

I don't make predictions about development timelines within OpenStack.

Yes, I think (4) should be our endgame, and is certainly the most
future-proof approach.  I haven't thought through in detail nor spoken with
the ops community at all about how disruptive such a transition might be.

Thinking just now, I suspect any such transition needs a minimum of one
(probably 2) release cycles.  Theoretically:

- introduce top-of-main code that drops to unpriv uid if root (could
theoretically be done in current N cycle)
- change required deployment method during upgrade to release N+1
- In N+1 cycle require starting as root (or similar)
- In N+1 change top-of-main code to fork-privsep-then-drop instead of
drop-then-later-use-sudo
- So by the time N+2 is deployed we're done.

If we want to give more notice and manage a longer deprecation cycle before
requiring a start-as-root deployment (and I think we want both these
things), then expand as appropriate.

I suspect the change to deployment method will be easier to communicate and
less unpleasant if we do "every" openstack service in the one
tear-the-bandaid-off cycle rather than drag this out over years.  This of
course requires substantial cross-project consensus, coordination, and
timing.   Once the laughing subsides and we assume that isn't going to
happen, then we will need something machine-readable and in-tree that
correctly communicates the desired per-service approach at that point in
time - perhaps we could publish (eg) systemd unit files for our services
and adjust those to User=root/not-root as services switch to the new method
over time.  This requires communicating when in the upgrade cycle systemd
unit files (or the implied equivalents) should be updated, so goto 10 ;)

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


More information about the OpenStack-dev mailing list