Open Stack

On Fri, Oct 31, 2014 at 12:12 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 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.
>
++

The Neutron team made this a priority focus on Juno, and in Kilo we'll
wrap this up and we should be able to declare nova-network as
deprecated in Kilo. This was a large undertaking but it's been great
to have the support of many people in the community on this.

> [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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev