Open Stack

In the spirit of summarizing conversations that have been had, I'd like
to point people that are interested at the Devstack FUTURE.rst document
- https://github.com/openstack-dev/devstack/blob/master/FUTURE.rst

This is an attempt by the Devstack team recently to write down a "where
are we going" document, which helps contributors and reviewers figure
where we are headed, and help us along that path.

A big piece of this is external Devstack plugins, which lets a project
keep their Devsack enable code within their own source tree, and let
people easily add their project to a local devstack with a single
``enable_plugin`` line. (And lets you even do gate jobs with pretty
minimal additional configuration). I've been working with the ec2api,
glusterfs, and opendaylight folks on their initial plugins over the past
couple of weeks and the results have been really promising that this is
a much better long term evolution for everyone. Once we get a few more
examples live and working, I think we'll be ready for a best practices
document in the devstack docs tree.

== Grenade ==

Based on the early successes here, I think Grenade is going to need to
go a similar path.

Part of what made doing Devstack plugins out of tree pretty clear was
that extras.d/ already defined a pretty reasonable set of phases, and we
had a bunch of projects that were already supported in tree in that
model. I'm sure we'll need some additional hook points in the future,
but we can roll that out in a backwards compatible way, or at least with
a long enough multi cycle deprecation that everyone can catch up.

For grenade, we've got 2 call out interfaces we need to care about.

1) the upgrade-* scripts

This + the from-/within- parts are all project specific, and you can
imagine how that could be moved out of tree if we guarunteed some
exported variables (like TOP_DIR) and move things like etc saving and
db-sync into common call paths. It's some work, but not really much new
invention.

2) resource survivability

In grizzly this was done ad-hoc, and we broke it for a while. In juno we
rebuilt a tool (javelin2) to try to give us a unified view of the world.
That turned out more difficult and more coupled that we expected.

I think for Liberty we need to step back on this and define the
interface, and let the implementations evolve behind it.

So we need something like:

resources.sh [create|verify|verify-noapi|delete]

old:
   resources.sh create
   resources.sh verify
downforupgrade:
   resources.sh verify-noapi
new:
   resources.sh verify
done:
   resources.sh delete

in the create phase you build your resources, we call out to verify
before we shut down services, after services are down we call
verify-noapi, and after they are up again we call verify. We need 2
verify calls because we want to test that things like computes weren't
deleted when nova-compute was down.

The back end for these might be openstack cli commands, a chunk of
python code, ansible, doesn't really matter much. The interface contract
should provide us isolation for that.


I think all of this is probably a Liberty timeline, because I just can't
imagine anyone getting around to it still in this cycle.

Which leaves the open question of additional project support in Grenade.
I think right now we should not add much more to Grenade during this
cycle, because I expect that's more we have to unwind in the next. So
for projects not in upgrade testing yet, lets hold off. Will try to have
a prototype up for Vancouver discussion and make things a lot more
inclusive for projects in Liberty.

	-Sean

-- 
Sean Dague
http://dague.net