[openstack-dev] [grenade] upgrades vs rootwrap
gus at inodes.org
Mon Jun 27 02:02:35 UTC 2016
On Fri, 24 Jun 2016 at 20:48 Sean Dague <sean at dague.net> wrote:
> On 06/24/2016 05:12 AM, Thierry Carrez wrote:
> > I'm adding Possibility (0): change Grenade so that rootwrap filters from
> > N+1 are put in place before you upgrade.
> If you do that as general course what you are saying is that every
> installer and install process includes overwriting all of rootwrap
> before every upgrade. Keep in mind we do upstream upgrade as offline,
> which means that we've fully shut down the cloud. This would remove the
> testing requirement that rootwrap configs were even compatible between N
> and N+1. And you think this is theoretical, you should see the patches
> I've gotten over the years to grenade because people didn't see an issue
> with that at all. :)
> I do get that people don't like the constraints we've self imposed, but
> we've done that for very good reasons. The #1 complaint from operators,
> for ever, has been the pain and danger of upgrading. That's why we are
> still trademarking new Juno clouds. When you upgrade Apache, you don't
> have to change your config files.
In case it got lost, I'm 100% on board with making upgrades safe and
straightforward, and I understand that grenade is merely a tool to help us
test ourselves against our process and not an enemy to be worked around.
I'm an ops guy proud and true and hate you all for making openstack hard to
upgrade in the first place :P
Rootwrap configs need to be updated in line with new rootwrap-using code -
that's just the way the rootwrap security mechanism works, since the
security "trust" flows from the root-installed rootwrap config files.
I would like to clarify what our self-imposed upgrade rules are so that I
can design code within those constraints, and no-one is answering my
question so I'm just getting more confused as this thread progresses...
What are we trying to impose on ourselves for upgrades for the present and
near future (ie: while rootwrap is still a thing)?
A. Sean says above that we do "offline" upgrades, by which I _think_ he
means a host-by-host (or even global?) "turn everything (on the same
host/container) off, upgrade all files on disk for that host/container,
turn it all back on again". If this is the model, then we can trivially
update rootwrap files during the "upgrade" step, and I don't see any reason
why we need to discuss anything further - except how we implement this in
B. We need to support a mix of old + new code running on the same
host/container, running against the same config files (presumably because
we're updating service-by-service, or want to minimise the
service-unavailability during upgrades to literally just a process
restart). So we need to think about how and when we stage config vs code
updates, and make sure that any overlap is appropriately allowed for
C. We would like to just never upgrade rootwrap (or other config) files
ever again (implying a freeze in as_root command lines, effective ~a year
ago). Any config update is an exception dealt with through case-by-case
process and release notes.
I feel like the grenade check currently implements (B) with a 6 month lead
time on config changes, but the "theory of upgrade" doc and our verbal
policy might actually be (C) (see this thread, eg), and Sean above
introduced the phrase "offline" which threw me completely into thinking
maybe we're aiming for (A). You can see why I'm looking for clarification
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev