settingsLogin | Registersettings

[OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

0 votes

All,

Last Thursday, the board did not act on any of our recommendations. The Board is reconsidering one of the guiding principles from Hong Kong - DefCore is trying to define a minimum base definition for OpenStack. Instead, they've asked us for multiple Trademark proposals.

ACTION ITEM: I'd be interested in hearing suggestions from the committee that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2. I'm open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).

I'd ask you to consider two items in preparation:

1) Sean Dague's Layers Model: https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or "big tent" which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob


Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140922/71a8cb4d/attachment-0001.html

asked Sep 22, 2014 in defcore-committee by Rob_Hirschfeld_at_de (1,900 points)   1 4
retagged Apr 14, 2015 by admin

11 Responses

0 votes

Hi Rob, I may have heard a different output from the Board call - which
was that the Foundation staff would work on some multi-TM proposals and
share them with the DefCore committee/Board. So Jonathan, Mark and Lauren
may already be working on them.

Personally, I think having more than one trademark usage doesn't undermine
the great work of DefCore so far. My thoughts on a simple multi-TM
structure that might serve the market are:

  • OpenStack Software (TM) for distributions, that would include all
    designated sections and core capabilities;
  • OpenStack Compute (TM) for services running all designated sections
    and core capabilities except for OpenStack Storage designated
    sections/core capabilities;
  • OpenStack Storage (TM) for services running the object storage
    designated sections and core capabilities (essentially SWIFT).

Best,
Simon

On Mon, Sep 22, 2014 at 2:09 PM, wrote:

All,

Last Thursday, the board did not act on any of our recommendations. The
Board is reconsidering one of the guiding principles from Hong Kong ?
DefCore is trying to define a minimum base definition for OpenStack.
Instead, they?ve asked us for multiple Trademark proposals.

ACTION ITEM: I?d be interested in hearing suggestions from the committee
that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2.
I?m open to having a working session before that to brainstorm options
(possibly with Mark or Jonathan).

I?d ask you to consider two items in preparation:

1) Sean Dague?s Layers Model:
https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or ?big tent? which
seems to be part of the OpenStackSV output: Monty
http://inaugust.com/post/108 and Randy
http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob

______________________________

Rob Hirschfeld

cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle

Please note, I am based in the CENTRAL (-6) time zone


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 23, 2014 by Simon_Anderson (660 points)   1
0 votes

Simon,

While I love the tenor of your approach, I think we need at least three more:

  1. Distributions (which I consider to be Red Hat, Canonical, and SUSE only) are currently shipping 100% of the integrated release, and they?ve expressed interest in a mark that represents that. So your proposed ?OpenStack Software? mark would more likely fit products (Piston OpenStack, CloudScaling OCS, Nebula One, etc).

  2. The proposed OpenStack Compute and OpenStack Storage would also need to apply to software and hardware products (as opposed to services) such as IBM?s whatever-that-thing-is-called.

I think it?s increasingly confusing to refer to swift-related things as ?Storage?, since that excludes Cinder- or Manila-related things.

An alternative approach would be to have just three marks:

  • OpenStack Distribution (100% of the integrated release)
  • Certified OpenStack (what?s currently covered by DefCore, being core capabilities and designated sections)
  • Powered by OpenStack Components (includes one or more of the core capabilities with the relevant designated sections for each capability)

The third mark would be a replacement for ?OpenStack Compute?, ?OpenStack Storage?, etc, and would prevent mark sprawl.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 22, 2014, at 10:43 PM, Simon Anderson wrote:

Hi Rob, I may have heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.

Personally, I think having more than one trademark usage doesn't undermine the great work of DefCore so far. My thoughts on a simple multi-TM structure that might serve the market are:
OpenStack Software (TM) for distributions, that would include all designated sections and core capabilities;
OpenStack Compute (TM) for services running all designated sections and core capabilities except for OpenStack Storage designated sections/core capabilities;
OpenStack Storage (TM) for services running the object storage designated sections and core capabilities (essentially SWIFT).

Best,
Simon

On Mon, Sep 22, 2014 at 2:09 PM, wrote:
All,

Last Thursday, the board did not act on any of our recommendations. The Board is reconsidering one of the guiding principles from Hong Kong ? DefCore is trying to define a minimum base definition for OpenStack. Instead, they?ve asked us for multiple Trademark proposals.

ACTION ITEM: I?d be interested in hearing suggestions from the committee that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2. I?m open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).

I?d ask you to consider two items in preparation:

1) Sean Dague?s Layers Model: https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or ?big tent? which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob


Rob Hirschfeld

cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle

Please note, I am based in the CENTRAL (-6) time zone


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 23, 2014 by Joshua_McKenty (540 points)   1
0 votes

Dell Customer Communication

From: Simon Anderson [mailto:simon at dreamhost.com] Hi Rob, I may have
heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.

Simon, I heard a lot of different positions taken. There was no clear guidance from the board in this regard and I believe our charter is to propose a variety of options for discussion. One could/should be "stay the course" and others should explore "levels" like the TC are discussing. Another path would be to accelerate the "submarks" like you've suggested as an addition to the core/base mark we've put into the process.

My issue is NOT with the changes proposed (there are several reasonable options) but with the continuous thrash in the board meeting that dilutes our effectiveness. These issues and discussions should have been raised before the meeting so that we could adjust the agenda.

responded Sep 23, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
While I love the tenor of your approach, I think we need at least three more:

Thank you both! Yes, we need more alternatives for discussion. Anyone willing to expand the pool with some non-traditional choices?

responded Sep 23, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

Rob, candidly, I think you are way overstating things and being
disrespectful of the Board in referring to the careful discussion and
debate around DefCore as "thrash".

The Board is very diverse, as it should be, and in the thick of considering
an extremely important issue that will have ramifications for the health
and growth of the OpenStack community in years to come. It's very important
that members of the Board feel fully able to take time to consider and
respond to evolving community inputs on DefCore, without being criticized
for not dancing to any other stakeholders tune.

I think you are getting too personally attached to the DefCore process.
You've been instrumental in leading it so far, but you should carefully
think about whether you can shift to the more patient, objective and
non-judgmental approach that will be needed to see it through to its
conclusion.

Best,
Simon

On Tue, Sep 23, 2014 at 9:36 AM, wrote:

Dell Customer Communication

From: Simon Anderson [mailto:simon at dreamhost.com] Hi Rob, I may have
heard a different output from the Board call - which was that the
Foundation staff would work on some multi-TM proposals and share them with
the DefCore committee/Board. So Jonathan, Mark and Lauren may already be
working on them.

Simon, I heard a lot of different positions taken. There was no clear
guidance from the board in this regard and I believe our charter is to
propose a variety of options for discussion. One could/should be "stay
the course" and others should explore "levels" like the TC are discussing.
Another path would be to accelerate the "submarks" like you've suggested as
an addition to the core/base mark we've put into the process.

My issue is NOT with the changes proposed (there are several reasonable
options) but with the continuous thrash in the board meeting that dilutes
our effectiveness. These issues and discussions should have been raised
before the meeting so that we could adjust the agenda.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 23, 2014 by Simon_Anderson (660 points)   1
0 votes

I?d like to nominate Simon to take over my co-chair position. I?m done.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 23, 2014, at 11:03 AM, Simon Anderson wrote:

Rob, candidly, I think you are way overstating things and being disrespectful of the Board in referring to the careful discussion and debate around DefCore as "thrash".

The Board is very diverse, as it should be, and in the thick of considering an extremely important issue that will have ramifications for the health and growth of the OpenStack community in years to come. It's very important that members of the Board feel fully able to take time to consider and respond to evolving community inputs on DefCore, without being criticized for not dancing to any other stakeholders tune.

I think you are getting too personally attached to the DefCore process. You've been instrumental in leading it so far, but you should carefully think about whether you can shift to the more patient, objective and non-judgmental approach that will be needed to see it through to its conclusion.

Best,
Simon

On Tue, Sep 23, 2014 at 9:36 AM, wrote:
Dell Customer Communication

From: Simon Anderson [mailto:simon at dreamhost.com] Hi Rob, I may have
heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.

Simon, I heard a lot of different positions taken. There was no clear guidance from the board in this regard and I believe our charter is to propose a variety of options for discussion. One could/should be "stay the course" and others should explore "levels" like the TC are discussing. Another path would be to accelerate the "submarks" like you've suggested as an addition to the core/base mark we've put into the process.

My issue is NOT with the changes proposed (there are several reasonable options) but with the continuous thrash in the board meeting that dilutes our effectiveness. These issues and discussions should have been raised before the meeting so that we could adjust the agenda.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 23, 2014 by Joshua_McKenty (540 points)   1
0 votes

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.

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

But this means that you couldn't use this mark is say, you provide ObjectStore but it's not swift. You provide block storage, but it doesn't use the parts of Cinder identified by DefCore process. If you substitute foundational pieces, the only mark you can use is the component marks that you incorporate. And those component marks should also be certified through testing as defined by the full tempest test suite for that component at that release.

Which means to get an "OpenStack XXX" mark, you need to pass Refstack tests as identified for the release you want the mark on.

Then all three sets of marks could be certified with testing to back them up and we have a real certification program.

--Rocky

-----Original Message-----
From: RobHirschfeld at Dell.com [mailto:RobHirschfeld at Dell.com]
Sent: Tuesday, September 23, 2014 9:39 AM
To: joshua at pistoncloud.com; simon at dreamhost.com
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

From: Joshua McKenty [mailto:joshua at pistoncloud.com]

While I love the tenor of your approach, I think we need at least three more:

Thank you both! Yes, we need more alternatives for discussion. Anyone willing to expand the pool with some non-traditional choices?


Defcore-committee mailing list

Defcore-committee at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 23, 2014 by Rochelle_Grober (7,040 points)   1 3 3
0 votes

Simon,

Glad you are sharing this feedback with me (and the list). Throughout this process, we (and I personally) have adapted to significant community feedback and responded in a measured way. I take my role as a neutral representative very seriously and strive to speak for many opinions that I?ve heard instead of my own position. That includes positions that YOU have stated. I?d happily allow someone else to lead (or co-lead) this process ? it has been a substantial personal investment for which I?ve drawn negative attention and comments.

Regarding ?thrash? ? I do believe that is the correct term. If the OpenStack board is to succeed, we need to have working sessions and committee discussion that actually produce real results. DefCore had a very open dialog about these issues leading up to the Board meeting. Unless we want to meet much more often (which I would support) then the Board members with strong positions should be active in the committees so that all sides of the issue can be heard where there is sufficient time to address them. If any of these issues were raised before the meeting based on the detailed report I submitted then I would have withdrawn the recommendations and allowed time for other topics.

Personally, I think additional marks are reasonable. They have been part of the stated plan from the start and we intentionally delayed them so that we nail down the smallest definition first. If that is now considered blocking progress then let?s address the suggest marks and keep moving.

Rob

From: Simon Anderson [mailto:simon at dreamhost.com]
Sent: Tuesday, September 23, 2014 1:04 PM
To: Hirschfeld, Rob
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

Rob, candidly, I think you are way overstating things and being disrespectful of the Board in referring to the careful discussion and debate around DefCore as "thrash".

The Board is very diverse, as it should be, and in the thick of considering an extremely important issue that will have ramifications for the health and growth of the OpenStack community in years to come. It's very important that members of the Board feel fully able to take time to consider and respond to evolving community inputs on DefCore, without being criticized for not dancing to any other stakeholders tune.

I think you are getting too personally attached to the DefCore process. You've been instrumental in leading it so far, but you should carefully think about whether you can shift to the more patient, objective and non-judgmental approach that will be needed to see it through to its conclusion.

Best,
Simon

On Tue, Sep 23, 2014 at 9:36 AM, > wrote:
Dell Customer Communication

From: Simon Anderson [mailto:simon at dreamhost.com] Hi Rob, I may have
heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.

Simon, I heard a lot of different positions taken. There was no clear guidance from the board in this regard and I believe our charter is to propose a variety of options for discussion. One could/should be "stay the course" and others should explore "levels" like the TC are discussing. Another path would be to accelerate the "submarks" like you've suggested as an addition to the core/base mark we've put into the process.

My issue is NOT with the changes proposed (there are several reasonable options) but with the continuous thrash in the board meeting that dilutes our effectiveness. These issues and discussions should have been raised before the meeting so that we could adjust the agenda.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 24, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

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:

responded Sep 24, 2014 by John_Dickinson (10,400 points)   2 6 10
0 votes

-----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:

responded Sep 25, 2014 by Rochelle_Grober (7,040 points)   1 3 3
...