On Fri, Oct 31, 2014 at 12:12 PM, Russell Bryant <rbry...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
