Open Stack

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
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