Open Stack

On Sep 22, 2014, at 5:10 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:

> On Mon, Sep 22, 2014 at 12:33 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>> On Sep 22, 2014, at 3:11 PM, Tim Bell <Tim.Bell at cern.ch> wrote:
>> 
>>> 
>>> On 22 Sep 2014, at 20:53, Doug Hellmann <doug at doughellmann.com> wrote:
>>> 
>>>> 
>>>> On Sep 19, 2014, at 6:29 AM, Thierry Carrez <thierry at openstack.org> wrote:
>>>> 
>>>>> Monty Taylor wrote:
>>>>>> I've recently been thinking a lot about Sean's Layers stuff. So I wrote
>>>>>> a blog post which Jim Blair and Devananda were kind enough to help me edit.
>>>>>> 
>>>>>> http://inaugust.com/post/108
>>>>> 
>>>>> Hey Monty,
>>>>> 
>>>>> As you can imagine, I read that post with great attention. I generally
>>>>> like the concept of a tightly integrated, limited-by-design layer #1
>>>>> (I'd personally call it "Ring 0") and a large collection of "OpenStack"
>>>>> things gravitating around it. That would at least solve the attraction
>>>>> of the integrated release, suppress the need for incubation, foster
>>>> 
>>>> I’m not sure I see this change reducing the number of incubated projects unless we no longer incubate and graduate projects at all. Would everything just live on stackforge and have a quality designation instead of an “officialness” designation? Or would we have both? ATC status seems to imply we need some sort of officialness designation, as you mention below.
>>>> 
>>> 
>>> The quality designation is really important for the operator community who are trying to work out what we can give to our end users.
>>> 
>>> Offering early helps to establish the real-life experience and give good feedback on the designs.  However, the operator then risks leaving their users orphaned if the project does not get a sustainable following or significant disruption if the APIs change.
>>> 
>>> The packaging teams are key here as well. When do Ubuntu and Red Hat work out the chain of pre-reqs etc. to produce installable packages, packstack/juju tool support ?
>>> 
>>> We do need to have some way to show that an layer #2 package is ready for prime time production and associated criteria (packages available, docs available, >1 company communities, models for HA and scale, …)
>> 
>> 
>> Right. I’m trying to understand if we are talking about doing that *instead* of our existing incubation/graduation process, or in addition to that process as a new thing. I like the idea of adding a quality designation. I’m not sure replacing our existing process with that designation is a good idea.
>> 
> 
> A "production ready" tag wouldn't replace the incubation process
> because incubation isn't about that. Also, the incubation process
> would go away because the TC wouldn't be in the business of adding
> projects to the integrated gate any more.
> 
> The content of integrated release would be based on a use-case-based
> scope definition, which is satisfied by the projects in the "Layer #1"
> list. I think it's interesting to think about other use-cases, and
> those could well inform the trademark discussion in the long term, but
> I think we need to start with one use case, and I would like to think
> this is one we can all agree on as central to the mission of
> OpenStack. That doesn't invalidate other use cases. And it doesn't
> make things not in Layer #1 suddenly become not-OpenStack. (A triple
> negative? Yep.)
> 
> One of the primary effects of integration, as far as the release
> process is concerned, is being allowed to co-gate with other
> integrated projects, and having those projects accept your changes
> (integrate back with the other project). That shouldn't be a TC

The point of integration is to add the projects to the integrated *release*, not just the gate, because the release is the thing we have said is OpenStack. Integration was about our overall project identity and governance. The testing was a requirement to be accepted, not a goal.

If there is no incubation process, and only a fixed list of projects will be in that new layer 1 group, then do contributors to the other projects have ATC status and vote for the TC? What is the basis for the TC accepting any responsibility for the project, and for the project agreeing to the TC’s leadership?

Based on what you’ve said, I’m afraid that this change makes project governance murkier, and introduces challenges to accomplish some of the unifying cross-project work that we have recently discussed as being so important.

> decision, and the decision to cogate with another project should be up
> to the projects themselves. If Nova feels that supporting the Ironic
> virt driver is important, Nova would agree to a two-project gate with
> Ironic. Other projects that Nova also gates with would not need to
> participate (eg, a change to Glance would also test Nova, but wouldn't
> necessarily run the nova-ironic test). I think this can be extended
> out to a "big tent" far better than our current gating system.
> 
> Whether or not there is a process to apply for / get the "production
> ready" sticker would no longer be related to being part of the release
> process or gate tests. Of course, it's essential this includes
> feedback from users and operators. For what it's worth, I would want
> to see at least one production deployment of a project - and get
> feedback from the operators of said deployment - before I would feel
> comfortable calling it production-ready.
> 
> -Devananda
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev