← Back to team overview

openstack team mailing list archive

Re: Running for Nova PTL

 

2012/2/23 Duncan McGreggor <duncan@xxxxxxxxxxxxx>:
> Soren, if elected, by what processes/policies etc. would you
> accomplish these goals?

Well, there are limits to what a PTL really can do :)

However, in practical terms there are a number of things I'd like us to
do:

 * I'd like us to look at the various components of Nova and thoroughly
   document (in prose as well as as tests) their API and expected
   behaviour. It's very tempting to change (in major or minor ways)
   these API's on a whim since we control both ends of the channel
   (often even in the same patch), but this a distributed system.
   Upgrades across an entire Nova installation are not instantaneous,
   and shouldn't have to be. We need to be more aware of the interfaces
   between components and the fact that they may not be in perfect sync.

 * In a similar vein, while we do a good job ensuring db schema upgrades
   work well, the code doesn't support anything other than the newest
   schema it knows about. Or rather, if it does, it's by accident.
   This makes it exceedingly difficult to upgrade a Nova installation
   peacemeal.

 * I'd like to revamp the virtualisation subsystem to move much more
   behavioural logic into a superclass and have the actual drivers be
   only the glue code to make the individual hypervisors work.

 * As I wrote in my response to Robert earlier in this thread, I'd like
   to see more branches pop up specific to particular subsystems. I'd
   like to make it easier to get features landed somewhere and let them
   mature there before they hit trunk.

 * I'd like to have much more frequent releases, and I mean *actual*
   releases, not just milestones. Each with merge windows, QA phases,
   release artifacts, etc.

 * Lots of other things I'll try to elaborate on over the next few
   days.

> Are there blueprints that already exist which
> you would rally folks around? Or would you introduce a new effort to
> more thoroughly componentize OpenStack?
>
> More specifically, how do you envision:
>
> 1) clarifying what needs to be done

I don't expect to do this all on my own. I'd like to set some overall
topics for the release cycle and try to seed the conversations about
these efforts (as I'm trying to do right now), but I'd really, really
like for everyone else to help identify all of this stuff and find
issues you care about.

> 2) building consensus around this, and

Excellent question. I can't force anyone to suddenly think QA and unit
tests are the most important things in the world. :)  I think there's a
strong correlation between my chances of getting elected and the how
much of a pre-existing consensus there is around the issues (and issues
like them). If I get elected, it's because people already think these
things are important, so it shoulnd't be too hard. Or so I hope.

> 3) accomplishing these goals? (it's a lot of work!)

I hope the rest of my e-mail sheds a bit of light on this.

-- 
Soren Hansen             | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/


References