Open Stack

Dissolving the integrated release without having a solid plan and replacement is difficult to communicate to people who depend on OpenStack. We’re struggling on that front.

That said, I’m still optimistic about project structure reform and think it could be beneficial to the development community and users if it’s executed well. It gives us the opportunity to focus on a tighter core of services that are stable, reliable and scalable, while also recognizing more innovation that’s already happening in the community, beyond the existing integrated release. Coming out of the ops meetup in Philadelphia yesterday, a few things were clear:

- Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence.
- They also want some kind of bar or filter for community projects, to provide guidance beyond it’s in or out of the community. Tags can help with the nuances once they’re in the tent, but I think there’s some support for a bit higher bar overall. 
- That said, several people expressed they did not want duplication to prevent a project from making it into the tent. They would like to have options beyond the core set of projects
- The layers concept came back to play. It was clear there was a distinct dropoff in operators running projects other than nova, keystone, glance, cinder, horizon and neutron
- The operators community is keen to help define and apply some tags, especially those relevant to maturity and stability and general operability

(I know several of you were at the ops meetup, so please jump in if I’ve missed or misrepresented some of the feedback. Notes from the session https://etherpad.openstack.org/p/PHL-ops-tags.)

Based on feedback and conversations yesterday, I think it’s worth evolving the overall project criteria to add 1) a requirement for contributor diversity, 2) some criteria for maturity like documentation, test coverage and integration/dependency requirements, and 3) make sure there are no trademark issues with the project name, since it will be referred to as an OpenStack project. I’m also unclear how we’re planning to refer to these projects, as “Foo, an OpenStack community project” but not “OpenStack Foo"?

For tags, I think defining a set of projects based on a broad reference architecture / use case like "base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, "compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects.

Getting this worked out before the Kilo release would be valuable, because having the “last” integrated release without a clear plan forward creates some real concerns for those running or productizing the software. Not all tags or implementation details need to be defined, of course, but we should be able to communicate a solid plan for the layers and categories of tags, as well as the different bodies who may be involved in defining tags (ops community, etc) before expanding. 


> On Mar 10, 2015, at 2:02 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 
> On 03/10/2015 02:56 PM, Thierry Carrez wrote:
>> Russell Bryant wrote:
>>> One point of clarification:
>>> 
>>> On 03/10/2015 02:28 PM, Gabriel Hurley wrote:
>>>> Even more concerning is the sentiment of "projects we want to
>>>> consciously drop" from Russell's original email.
>>> 
>>> This was in reference to criteria defined in:
>>> 
>>> http://governance.openstack.org/reference/incubation-integration-requirements.html
>>> 
>>> For example, we previously had a strict requirement *against*
>>> duplication of functionality among OpenStack projects unless it was with
>>> intent and with a clear plan to replace the old thing.  In this new
>>> model, that would be a requirement we would consciously drop.
>> 
>> It's a requirement we *already* consciously dropped when we approved the
>> new projects requirements. Or do you mean you want to come back on that
>> decision[1]?
> 
> No, I don't want to come back on it.  It was obviously a poorly worded
> comment.  It was an attempt to say that I'd like it if we were closer to
> having tags that covered most of those requirements, except for the
> things we no longer care about, such as the example given.
> 
> -- 
> Russell Bryant
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev