Open Stack

On 07/01/2013 08:41 AM, John Dickinson wrote:
> 
> On Jul 1, 2013, at 8:03 AM, Mark McLoughlin <markmc at redhat.com>
> wrote:
> 
>> Hey Thierry
>> 
>> I actually didn't notice this go by last week, the other thread got
>> all the attention.
>> 
>> On Wed, 2013-06-26 at 14:51 +0200, Thierry Carrez wrote:
>>> Hi everyone,
>>> 
>>> Yesterday at the TC meeting we agreed that as a first step to 
>>> establishing programs, we should have a basic definition of them
>>> and establish the first (undisputed) ones.
>>> 
>>> We can solve harder questions (like if "horizontal efforts"
>>> should be a program or a separate thing, or where each current
>>> official repo exactly falls) as a second step.
>>> 
>>> So here is my proposal for step 1:
>>> 
>>> """ 'OpenStack Programs' are efforts which are essential to the
>>> completion of our mission, but which do not produce deliverables
>>> included in the common release of OpenStack 'integrated' projects
>>> every 6 months, like Projects do.
>> 
>> Hmm, this wasn't what I understood our direction to be.
>> 
>> And maybe this highlights a subtle difference in thinking - as I
>> see it, Oslo absolutely is producing release deliverables. For
>> example, in what way was oslo.config 1.1.0 *not* a part of the
>> grizzly release?
>> 
>> The idea that documentation isn't a part of our releases seems a
>> bit off too.
>> 
>> This distinction feels like it's based on an extremely constrained 
>> definition of what constitutes a release.
>> 
>>> Programs can create any code repository and produce any
>>> deliverable they deem necessary to achieve their goals.
>>> 
>>> Programs are placed under the oversight of the Technical
>>> Committee, and contributing to one of their code repositories
>>> grants you ATC status.
>>> 
>>> Current efforts or teams which want to be recognized as an
>>> 'OpenStack Program' should place a request to the Technical
>>> Committee, including a clear mission statement describing how
>>> they help the OpenStack general mission and how that effort is
>>> essential to the completion of our mission. Programs do not need
>>> to go through an Incubation period.
>>> 
>>> The initial Programs are 'Documentation', 'Infrastructure', 'QA'
>>> and 'Oslo'. Those programs should retroactively submit a mission
>>> statement and initial lead designation, if they don't have one
>>> already. """
>>> 
>>> This motion is expected to be discussed and voted at the next TC 
>>> meeting, so please comment on this thread.
>> 
>> It's funny, I think we're all fine with the idea of Programs but
>> can't quite explain what distinguishes a program from a project,
>> etc. and we're reaching for things like "programs don't produce
>> release deliverables" or "projects don't have multiple code
>> repositories". I'm nervous of picking a distinguishing
>> characteristic that will artificially limit what Programs can do.
> 
> I think the concern I have with the current discussions is that the
> definition is becoming so specific that we'll someday have such an
> over categorization of things to the point of "repos created on a
> Tuesday".
> 
> What is the end result here, and what are we trying to promote? I
> think we want to give ATC status to people who contribute to code
> that is managed as part of the OpenStack organization. In that sense,
> everything (ie nova, swift, neutron, cinder, etc) is a program,
> right? What happens if an existing "project" wants to deliver an
> independent code library? "Just put it in oslo!" may be the current
> answer, but moving a bunch of unrelated deliverables into oslo causes
> review issues (a separate review community) and may slow development.
> (that's actually not the argument I want to have in this email
> thread)
> 
> I'd suggest that everything we have today are "openstack programs".
> Many have multiple deliverables (eg a server side and a client side).
> As a specific example (only because it's what I'm most familiar with,
> not that this is something Swift is considering), if Swift wanted to
> separately deliver the swob library (replacement for WebOb) or our
> logging stuff, then they simply become another deliverable under the
> "Swift program".
> 
> I completely support (going back years now) the idea of having CI,
> QA, Docs, etc as additional "top-level" openstack things.
> 
> To reiterate, what are we trying to accomplish with further
> classification of code into programs and projects? What is lacking in
> the current structure that further classification (ie a new name)
> gets us?

I agree with John. I believe from my perspective, the point of this is
not pedantic taxonomy - but to answer the question "how do we say yes to
something that isn't itself a REST-based server codebase or its
corresponding client library" We have a very clear process for
completely new thought that is a server to be analyzed, incubated and
accepted. We also have a clear process for an existing project to spawn
a new code repo (I believe there is complete understanding that swift
could quite simply decide to make an openstack/swob repo and own it and
that's fine)

The thing that's murky - mainly because we started asking and got
nowhere - is what to do with things like TripleO or refstack and the
stuff they might produce - is how to deal with them. Like John mentions,
we could certainly start cramming things in to oslo - but that just
doesn't feel like the right thing. Neither does taking the things and
trying to find homes for them in moderately related projects (dib into
glance, orc and oac into heat perhaps)

So I think that instead of getting too down in the weeds about
discussion of whether or not a code repo exists or doesn't or produces a
tarball or doesn't - the original point I was trying to get at with the
programs idea was this:

A program is an effort that's trying to drive an outcome. It may or may
not have specific product releases, but the point of it is the mission
of the group and the outcome it's trying to produce.

Specific straw-man example missions:

- Infra - Ensure that the developers of OpenStack are supported through
tooling and automation.
- QA - Ensure that OpenStack is tested.
- Docs - Ensure that OpenStack is documented.
- Oslo - Reduce duplication of effort via the use of common code libraries
- TripleO - Ensure that OpenStack and boot and run itself
- refstack - Provide a reference implementation and FITS testing and
technical certification against that implementation for OpenStack clouds

Now - many of these have actual deliverables. Some are tied to releases.

Oslo produces oslo.config which is tied to our integrated releases. It
also produces hacking and pbr which are not released in cadence with the
rest of things.

QA produces tempest, which is not released at all, but is certainly a
software product.

Infra produces MANY libraries and pieces of software. None of them are
released in cadence with the rest of OpenStack. Some are libraries on
pypi. Some are a Continuously Deployed infrastructure.

Docs produces some documentation that is released in conjunction iwth an
OpenStack release, and some documentation that is not tied to an
OpenStack release.

TripleO is currently working on producing work both as patches to
existing core projects as well as several smaller utilities. It has not
been discussed if any of those utilities need to be tied to an OpenStack
release. If OAC/ORC get tied in to Heat, I imagine that they will be
more strongly tied to release cycle. I doubt diskimage-builder will want
to have a tied release cycle, and instead, like the client libraries,
will probably want to be multi-version aware.

So I think that tying a definition directly to whether or not there is a
release artifact or when that gets produced is missing the point and
wrong. The point is that there are _efforts_ that we want to address,
and those efforts may not have a clear cut simple "main" source code
repository.

Monty