[openstack-dev] TC election by the numbers

Russell Bryant rbryant at redhat.com
Fri Oct 31 17:12:14 UTC 2014


On 10/31/2014 12:17 PM, Matt Joyce wrote:
> On one hand, I agree a member of the TC should be a very active member
> of the development community.  Something I have not been, much to my shame.
> 
> However, there are obviously some fundamental issues in how the TC has been
> governing OpenStack in the past few releases.  Very serious issues in the
> project have been largely ignored.  Foremost in my mind, among them, is
> the lack of an upgradability path.  I remember there being large discussion
> and agreement to address this at folsom, and further back.  I have seen no
> meaningful effort made to address a functionality requirement that has been
> requested repeatedly and emphatically since as far back as austin.

I actually think there has been good progress here.

Nova, for example, has been working very hard on this for several
releases.  Icehouse was the first release where you were able to do a
rolling upgrade of your compute nodes.  This is tested by our CI system,
as well.

This continues to be a priority in Nova and across OpenStack.  Nova's
support for rolling upgrades continues to be improved.  We're also
seeing a push to apply what we've learned and implemented for Nova
across other projects.  We have a session about this in the
cross-project track.  There's a session in the Cinder track to discuss
it.  There's a related session in the Nova track.  There's a session in
the Olso track about the shared code part ... it is a priority, and very
good work is happening.

> I can raise other issues that continue to plague usership, such as neutron
> failing to take over for nova-network now two releases after it's planned
> obsolescence.  My concern, is that the TC comprised entirely of active 
> developers ( most of whom are full time on the open source side of this
> project ), is trapped in something of an echo chamber.  I have no real
> reason to suggest this is the case, beyond the obvious failure by the 
> project to address concerns that have been paramount in the eyes of users
> for years now.  But, the concern lingers.  

Again, this is an issue that has not been ignored.

In the Juno cycle, the TC did a series of project reviews, where we
identified key gaps between the project's current status and what we
expect from an integrated project.  Getting Neutron to where it can
finally deprecate and replace nova-network is the top issue for Neutron.
 We worked with the Neutron team to write up a gap analysis and
remediation plan [2].  A lot of very good progress was made in the Juno
cycle.  The Neutron team did a nice job.

I'm personally very hopeful that we can wrap up this deprecation issue
in the Kilo cycle.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html
[2]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

-- 
Russell Bryant



More information about the OpenStack-dev mailing list