openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

On Thu, Feb 23, 2012 at 9:17 AM, Soren Hansen <soren@xxxxxxxxxxx> wrote:
> I've put my name on the ballot for Nova PTL, and I'd like to explain
> what I expect to do (my platform, if you will).
>
> Nova is facing many separate, but related problems.
>
> * Nova is too big.
>   Very few (if any) core developers are comfortable reviewing every
>   part of the code base.  In itself, this isn't necessarily a problem,
>   but I think it would be valuable to try to somehow acknowledge that
>   the average focus is much narrower than "all of nova".

This has been one of my biggest concerns since I started using OpenStack...

> * Lots of things in Nova that should be orthogonal are not.
>   This problem is especially prevalent in the virtualisation layer. The
>   layout and number of disks you get attached to instances shouldn't
>   depend on the hypervisor you've chosen, but it does. There is lots
>   and lots and lots of logic embedded in both the libvirt and XenServer
>   drivers that isn't related to the hypervisor, but is a result of the
>   origin of these drivers.

And this has been my very biggest concern, as I believe it is the root
cause for other things which I am keenly interested in seeing
addressed (e.g., quality, maintainability, interoperability, etc.).

Soren, if elected, by what processes/policies etc. would you
accomplish these goals? 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
2) building consensus around this, and
3) accomplishing these goals? (it's a lot of work!)

Thanks,

d

> * The overall quality is decreasing
>   There's an almost unilateral focus on features across the board. The
>   topic of almost every session at the summit is some new feature.
>   There is very little focus on stability, predictability and
>   operation. Personally, I think that shows very clearly in the final
>   product.
>
> I'd like to try to shift our focus and turn the proverbial ship around.
>
> I'd like to remove any incentive to rush things into Nova trunk.
>
> 1. A much shorter release cycle (as Thierry also suggests[1]) would be
> very beneficial. Noone wants to have to wait an extra 6 months getting
> some new feature in just because it missed the feature freeze.  However,
> just a single month of delay... That should be manageable in most cases.
>
> 2. I'd like to make it more straight forward to have things mature
> somewhere separete from Nova trunk, but still make it easy to
> collaborate on them or get people to test them.
>
> 3. I'd like to encourage a stronger focus on QA and testing.
> Specifically, I'd love to have more people focused on making it easier
> to test things in Nova. Tempest is a great effort, but the unit test
> suite is our first line of defence. It should be fast and comprehensive.
> Right now, it's neither.
>
> 4. I'd like a stronger focus on extensibility and plugability.
>
> 5. I'd like us to rethink our configuration management strategy. So far,
> we've punted on it and deferred to deployers to choose between Puppet,
> Chef or whatever else to handle this. However, many things will crash
> and burn if the configuration of various components is out of sync with
> each other or with the database. This is particularly clear in the
> networking area.
>
> [1]: http://fnords.wordpress.com/2012/02/21/open-dev-releases-quality/
>
> --
> Soren Hansen             | http://linux2go.dk/
> Senior Software Engineer | http://www.cisco.com/
> Ubuntu Developer         | http://www.ubuntu.com/
> OpenStack Developer      | http://www.openstack.org/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp