Open Stack

Hi Mark,
We're getting closer, of that I'm sure.

On Sat, Nov 17, 2012 at 10:48 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Fri, 2012-11-16 at 14:14 -0600, Anne Gentle wrote:
>> Hi Mark,
>> Good points, I'll try to further delineate where I see differences.
>>
>> On Fri, Nov 16, 2012 at 11:57 AM, Mark McLoughlin <markmc at redhat.com> wrote:
>> > Hi Anne,
>> > On Fri, 2012-11-16 at 08:17 -0600, Anne Gentle wrote:
>> >>  there should be an end-result for an Incubation period to result
>> >> in a final destination that is not related to all the current
>> >> privileges given to Core projects.
>> >
>> > I think this is the bit where you're really trying to make a different
>> > proposal, but I don't fully understand it.
>> >
>> > My motion basically says that the end-resource of Incubation is "part of
>> > the OpenStack releases" or "not part of the OpenStack releases".
>> >
>> > What other end-result do you see?
>>
>> There will be projects that are released together that we all talk
>> about every week at the project meeting and at twice-annual in-person
>> events. These are called "nuclear" -- and "core" projects are also
>> welcomed to be part of the OpenStack release umbrella but will not get
>> all the associated privileges that three "nuclear" goals have -
>> compute, network, storage. Perhaps I am trying to define IaaS with
>> simpler terms since I don't have all the verbiage for defining
>> infrastructure.
>>
>> The process would be -- those projects not specifically "nuclear" will
>> have a different set of requirements to be called "core." Those
>> projects in "incubation" will be promoted to "core" if they meet the
>> requirements to be called "core" and "core" drops the trademark
>> connotation but does get other privileges, yet to be defined in the
>> details.
>
> Ok, we can put aside the "trademark projects list" thing for a moment
> since you're also in favour of leaving that completely up to the Board,
> assuming the list is a subset of list of projects accepted into the
> OpenStack release by the TC.
>
> I think what you're proposing then is to:
>
>   1) Create a new category called "nuclear"

Listening more and reading more, I'm not sure if this is a good
proposal as it'll be shot down most likely. But yes, perhaps the
"infrastructure" in IaaS is what I would call nuclear - compute,
storage, network.

The "service" in "aas" needs the integrated goodness to make it usable
as a service - identity and a dashboard are these to me as well as
metering. Billing and Identity can be so plug-able though so I'm still
early on in a defined hardline here.

>   2) Move nova, swift, glance, cinder and quantum (keystone too?) into
>      this category

I think there are projects that should be held to the requirements an
integrated release has. They're probably all in nuclear and core.
Perhaps nuclear is only helpful to scope release management, CI,
integration testing, and doc. Hm. I would want "core" projects to get
benefits from the systems we provide but not overwhelm them.

>   3) Everything else - e.g. horizon, ceilometer, heat - would be in the
>      "core" category
>
>   4) The end-result of a positive incubation is being accepted into core

The end-result of a positive incubation would be clean clear
integration, probably meaning it should be a "core" project. It could
also become a gating project, couldn't it? Erg.

>   5) We somehow treat nuclear and core projects differently during
>      development

Hm. Good extraction and clarity sir. I'm pretty sure that some nuclear
projects (nova for example) would need to talk about image and volume
management at the summit for example. But the Summit track would be a
"compute" track including nova, glance, and cinder. Not a
track-per-project. But that's probably the direction we'll need to go
to stick to 4 days anyway.

>
> The bit I'm unclear about is (5) - exactly what are we talking about?
> Perhaps the release management, vulnerability management or stable
> branch teams would ignore these projects?

Not ignore by choice but by force of scale. When we have 20 core
projects we can't fit that into an hour weekly IRC meeting for
example. How do we provide incubation for practicing projects to learn
the "OpenStack" way when we can't scale very far? Perhaps this concern
about scale will be controlled by the speed at which projects are
added and I shouldn't let that cloud (ha!) my vision.

>
> Or, perhaps it's closer to your own heart? That the docs team wouldn't
> feel they were being forced into committing to fully documenting those
> projects?

The docs team has a known problem with defining a release. Often, open
source projects don't manage docs as strictly as we have so far. So
project-by-project doc only helps developers, not deployers or users.
Getting a project list up to 10, 12, 15, 20, means that only
"infrastructure" and "services" are documented, not project-by-project
docs other than what the devs create or embed in code. We have barely
any API doc contributors for example. And deployer doc contributors
are now really making names for themselves for install and config. So
I don't yet see a match between "release management per project" and
"document management per project" -- so yes this is the heart of the
issue for me -- scale, coverage, scope. Maybe I just need a little
more faith in "slowness is okay" and "coordinated not controlled" --
I'm okay with that. Again these are probably details and not
necessarily what the Board is asking for right now.

All this said, I think paragraph three is the only area where a
revised motion helps me come to consensus. I want a welcoming,
worthwhile incubation process, that's important to me. What's also
important is that we are ready to define the responsibilities to exit
incubation. This sentence just isn't enough... "demonstrate" and
"suitability" and "inclusion" and "coordinated" aren't enough...

"We see Incubation as a trial period where promising projects have the
  opportunity to demonstrate their suitability for inclusion in our
  coordinated releases."

... but I'm completely willing to have faith in the process of a
further discussion shaping the details.

Whew!

Anne

>
> I don't like the idea of second-class projects, but I'm sympathetic to
> the docs issue. I'd like to think the number of docs contributors would
> grow as new projects are added (i.e. people from those projects would
> contribute to the docs). Perhaps full docs coverage would be a
> requirement to graduate from Incubation?
>
> If we dug into the details of (5) a bit more, it definitely would be a
> fine motion for the TC to vote on.
>
> Cheers,
> Mark.
>