Open Stack

On Sep 23, 2014, at 12:06 PM, Rochelle.RochelleGrober <rochelle.grober at huawei.com> wrote:

> Taking up the gauntlet.
>  
> What I heard from the board meeting was:
>  
> DefCore did and is doing what it is supposed to do:  Identify mature, critical widespread OpenStack functionality and corresponding code that represents the foundational pieces of the OpenStack contributions for a specific release; identify tests which would certify these foundational components.  No politics.  All technical.  What DefCore is really saying about these parts identified by DefCore is that they are community vetted, tested under fire, in the wild, and represent the solid and mature parts of OpenStack; these identified parts can be trusted.  Well, as well as they are tested.  We might want to change bug priorities in the projects such anything affecting identified core functionality/code gets marked critical and gets fixed first, but that’s another issue.
>  
>  
> Now, these foundational components are just that, components.  As the tent expands, we’ll have a lot more components that meet the 12 aspects of foundational and yet will be able to operate exclusive of much or all of the rest of the OpenStack integrated releases.  So, we need to step forward with a plan that takes these realities into account.  But what DefCore is really saying is that these parts identified by DefCore are community vetted, tested under fire, in the wild and are important.
>  
> We appear to be most of the way to a solution with the full distro and the standalone components (but not the names):
> ·         OpenStack distro (OpenStack full stack??? Certified OpenStack?  Whole OpenStack?)
> ·         OpenStack component(powered by OpenStack XXX?)
> But the hard part is the mostly got it all parts or when other stuff is added to what would be considered an OpenStack product or distro.

I agree completely here. The first time I heard this idea was from Josh, and I think it's fantastic. Having one mark that calls the integrated release[1] "OpenStack" answers the main concern I've heard so far: calling some subset of the integrated release "openstack" (or at least labeling a subset group as a thing above other subsets).

Naming is hard, and unfortunately in this case, the names matter more than normal. FWIW, I like both "distro" and "full stack".

I also think that the idea of a second "components" mark helps answer the concerns of people who are shipping products that include a subset of the integrated release. This mark allows products to be accurately branded so as to promote interop (deployers and end-users know what's on the inside).

Importantly, the existing DefCore process work can be applied to these two proposed concepts. Basically, all of the capabilities and sections defined in the recent board proposal still apply. There are two high-level parts to finish. First, define capabilities and sections for the other projects in the integrated release. Second, slightly tweak the final proposal to match the proposed marks. That is, instead of proposing "here is your OpenStack mark definition", it would look something like "here's the buffet of capabilities and code--if you use everything, use mark A, otherwise mark B".

>  
> So, how about we define the third mark as: it is built on the DefCore identified code and contains no extensions or new code that displaces any of the DefCore identified set of functionality/code.  This would allow for:
> ·         Powered by OpenStack
> ·         Built on OpenStack
> ·         OpenStack Solid
> ·         Etc

I'm a little unclear on what this third mark adds. My understanding of the other two proposed marks (as I stated above) is that they would use the DefCore process. So this proposed mark seems to be defining a subset of the first mark as a thing. That was (my understanding of) the biggest roadblock to the board proposal, so I'd like to hear some more explanation of this.


--John



[1] I know that there are current discussions on the -dev mailing list and among the TC that may end up with getting away from something being called the "integrated release". I'm using the word "integrated release" here because that's what it's been called so far and as a stand in for whatever the TC ends up with as the set of projects falling under OpenStack governance.





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140923/7c9eecc5/attachment.pgp>