Open Stack

Thanks for the questions Jay, answers inline.

On 9/26/16, 8:39 PM, Jay Pipes wrote:
>Who decides what is integral to OpenStack and what merely "enhances" it,
>though? The TC? The DefCore group? The Board of Directors? One might say
>all three groups have a say in defining what "is OpenStack", no? And
>therefore all three groups would decide what is "integral" to OpenStack.

This will undoubtedly be the most difficult part of the transition, so
making these decisions transparently will be essential. As a starting
point I would suggest we use our existing definitions of Core and Optional
services found here: https://www.openstack.org/software/

Everything in the 'Core' section would fall within the definition of
OpenStack, everything else would live in the OpenStack Family. This isn't
a change that would happen overnight, and of course we¹d seek many rounds
of input from all interested parts of the community.

>We do indeed have a long way to go in improving the operator's
>experience for many OpenStack projects.
>
>However, remember that many of the OpenStack projects came into
>existence because operators were asking for a certain use case to be
>fulfilled. I'm uncertain how putting some projects into a
>not-really-OpenStack-but-related bucket will help operators much. Is the
>pain for operators that there are too many projects in OpenStack, or is
>the pain that those projects are not universally installable or usable
>in the same fashion?

Absolutely, listening to operators should continue to be the primary
driver for a lot of our decision making. For the last 3 or 4 summits I've
found the operator feedback sessions to be the most valuable, and at least
one led directly to a new feature (neutron purge).

Not being an operator myself I'd defer to seeking feedback from the ops
community during this process, but a few Big Tent related issues I've
heard include:

* Do I need to support *all* of these projects?
* Why doesn¹t everything follow the same release schedule any more?
* How many of these are mature enough to be useful?

>What is OpenStack's core purpose? :) The OpenStack mission is
>intentionally encompassing of a wide variety of users and use cases. The
>Big Tent, by the way, did not affect this fact. The OpenStack mission
>pre-exists the Big Tent. All the Big Tent did was say that projects that
>wanted to be official OpenStack projects needed to follow the 4 Opens,
>submit to TC governance, and further the mission of OpenStack.
>
>It sounds like you would like to limit the scope of the OpenStack
>mission, which is not the same as getting rid of the Big Tent. If that's
>the case, hey, totally cool with me :) But let's be specific about what
>it is you are suggesting.

OpenStack does not have a core purpose. Not one that everyone agrees on
anyway. Some would like it to be an Apache-like collection of loosely
related open source projects. Others would like to see it be a
laser-focused operating system for the data center. I'd say that it
started out closer to the latter and is slowly drifting towards the
former. The discussion surrounding the "Write down OpenStack Principles"
patch has shown us that the closest we've had to an official mission
statement until now was the result of a TC vote in 2011:

"A single product made of a lot of independent, but cooperating,
components."

Now obviously this is somewhat vague and open to interpretation, but to me
the "single product" part suggests a level of focus that is missing today.
This puts us in the position of deciding whether we need to re-focus
OpenStack to better match the mission statement, or change our mission
statement to better reflect reality. I'd like to do a bit of both. Limit
the scope of OpenStack to that of its core components, while providing a
framework for official projects that enhance its capabilities.


>Hmm, I disagree about that. I think that experience actually *has* shown
>us that there is a single set of rules that can/should be applied to all
>projects that wish to be called an OpenStack project.

We may have to agree to disagree here. Look at recent efforts to enforce
python 3 compatibility, for example. Some projects had reasons why they
didn't want to, others had reasons why they couldn't, and some simply
didn't view it as a priority. We'd be much more productive in defining and
enforcing rules like this if there was a narrower scope of projects they
applied to.

>> * Define OpenStack as its core components
>
>Which components would these be? Folks can (and will) argue with you
>that a particular service is critical and should be considered core. But
>differing opinions here will lead to a decision-making inertia that will
>be difficult to overcome. You've been warned. :)

See above. This definition already exists, but I acknowledge that it will
need to be iterated upon. I'd like to point out that there will be
benefits of being in the OpenStack Family, such as not needing to comply
with the more prescriptive rules as discussed above.

>> * Introduce a new home for complementary projects - The OpenStack Family
>> * Reinstate Stackforge as the primary incubator for new projects
>
>Having Stackforge as a separate Github organization and set of
>repositories was a maintenance nightmare due to the awkwardness of
>renaming projects when they "moved into OpenStack".

There's no reason that this would need a separate github structure, just
separate messaging and rules. Under this model, moving into OpenStack
would probably be a rare event. Moving into the OpenStack Family would be
much more common.

>Also, reminder: The Big Tent != the dissolution of Stackforge.

Perhaps, but it certainly took the spotlight away from it.

>Who gets to decide this graduation? The TC? The DefCore committee? The
>Board of Directors? What criteria would you use in the graduation
>requirements? Would they be technical criteria or governance/process
>criteria?

The would be two types of graduation: StackForge -> Family, and Family ->
OpenStack. The first would be mostly technical/governance. The second
would be mostly based on adoption rate. Moving from StackForge into The
OpenStack Family would indicate that we as a community are vouching for
this project being stable and useful. All or most of the rules that apply
to the Big Tent today would apply to the OpenStack Family. Moving from The
OpenStack Family to OpenStack would be a rarer event, and would indicate
that a project has become widely used enough to be considered a core
component in a significant percentage of deployments. Rules in OpenStack
may become stricter, with more requirements such as the py3 compatibility
discussed above.

>What technical benefits would graduating give to a project? If no
>technical benefits -- the benefits would be entirely marketing,
>political or reputational -- then should the *Technical* Committee be
>the group that decides whether a project graduates?

This is something we'll need to discuss in detail, especially in relation
to the requirements to be a StackForge project in the first place. Most of
the benefits are likely to be marketing, political, and reputational. If
the technical committee is the body defining these processes and
requirements, then it makes sense for them to be making the decisions.

>These are all questions that you will inevitably be asked to consider
>when you go (back down) the route you suggest. So, I think it's worth
>responding here in your TC candidacy mail.
>
>All the best,
>-jay

Thanks for the questions! It's great to have these issues discussed in the
open.

John


________________________________
Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.