Open Stack

One other thing I'd like to add on the Swift conundrum:

I went to the congress meetup and Martin Calado said something very interesting.  Rough paraphrase: you can't start to abstract the physical functions until you've virtualized them.  For Nova, the virtualization layer is the hypervisors.  For Swift, it is the virtualization layer.  So really, Swift is layer 0.  Which makes it really important but not always necessary.  But it also makes it valuable to people who don't want the cloud abstraction but still want the virtualization of its datacenter hardware.

--rocky

From: Rochelle.RochelleGrober [mailto:rochelle.grober at huawei.com]
Sent: Wednesday, September 24, 2014 5:55 PM
To: John Dickinson
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier






-----Original Message-----
From: John Dickinson [mailto:me at not.mn]
Sent: Tuesday, September 23, 2014 8:41 PM
To: Rochelle.RochelleGrober
Cc: Rob_Hirschfeld at Dell.com; joshua at pistoncloud.com; simon at dreamhost.com; Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier





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.





[Rocky Grober]

Let's see if I can make this third point more clear.  Defcore identifies capabilities *and* code that are mature and well used in the outside world.  Right now, in Havana, capabilities include nova and swift which is the crux of the definition issue as you can use either one without the other.  But when you are not including the other, there could/should still be a more overarching mark than just the "OpenStack Swift" or "OpenStack Nova" if you are using the OpenStack framework and not *replacing* OpenStack project(s) with proprietary or non-OpenStack projects.



So, here's a couple of examples:



Nova/Glance/Swift --> Powered by OpenStack

Nova/Glance/Ceph (used as ObjectStore) --> OpenStack Nova, OpenStack Glance - no general mark

Nova/Glance/Swift/Cinder+Ceph --> Powered by OpenStack - addition of Ceph does not replace an existing OpenStack integrated project



Swift/Keystone --> Powered by OpenStack

Swift/keystone/CloudStack -->  OpenStack Swift, OpenStack Keystone - no general mark

Swift/keystone/trove/mongoDB --> Powered by OpenStack - MongoDB doesn't replace any OpenStack integrated project



Now these examples are a bit stilted, but you I think you can better get what I am trying to say.  You can't use a general OpenStack Mark if you use a replacement code set for any function of an OpenStack "Core" capability set.



Any clearer?



--Rocky









--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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140925/833a7964/attachment-0001.html>