openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #07909
Re: Running for Nova PTL
I'd love to hear more specifics about what needs more focus. These
issues are large and have been the major focus of the core team for a
while.
> * 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".
As for services, a major amount of work has been done to improve the
situation, such as:
- volumes: once a name is agreed upon (cindr was vish's proposal)
volumes can be abstracted during folsom - the internals are now
separated and during essex you can deploy as seperate endpoints
- network: nova-network will be deprecated in folsom assuming
successful integration of quantum (as was discussed at the last PBB
meeting)
- identity: nova's user system was deprecated during diablo and being
removed in essex - a migration path exists
- ec2 compat: during essex ec2 access/secret was moved to keystone,
cert management was decoupled from API
Are there addition areas to make nova smaller?
For instance, a topic for folsom is how we can move drivers out of core.
> * 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.
There was a major push to fix many of the identified issues around
"parity" in Essex by Rackspace Public Cloud, Cloud Builders, and
Citrix. For instance the disk configuration issue you mentioned was
blueprinted at the last summit and fixed in Essex.
Are there specific bugs/blueprints that should be prioritized in folsom?
> * 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 think that your statement is harsh and over-reaching. Unlike
previous releases, we've tried to design the milestone structure to
have a focus on quality and uniform experience regardless of
deployment choices. While there are things that can be improved,
we've taken an iterative approach to improving the situation (both
during essex and then in discussions at the next summit)
I can think of few features that weren't in the name of parity
(features existing for only one configuration)
The work done by mtaylor & jblair on gating merges has lead to a much
saner trunk. During diablo our team would routinely spend a few hours
a day fixing trunk. During Essex the timeframe having a broken trunk
was the exception!
I look forward to further discussions about improving openstack
regardless of who is PTL.
Jesse
Follow ups
References