Open Stack

> On Oct 2, 2014, at 10:24 AM, Auld, Will <will.auld at intel.com> wrote:
> 
> Comment below:
>  
> From: Mark Collier [mailto:mark at openstack.org <mailto:mark at openstack.org>] 
> Sent: Thursday, October 02, 2014 6:37 AM
> To: Simon Anderson
> Cc: Defcore-committee at lists.openstack.org <mailto:Defcore-committee at lists.openstack.org>
> Subject: Re: [OpenStack-DefCore] progress - met w/ Foundation
>  
> Thanks SImon and Tim for reading and considering the proposal.  It’s a lot of words I know :)
>  
> The rationale behind it was to take the existing 2 programs that fall under “Powered” and update the technical requirements per Defcore output (to make it easy of existing licenses to understand and implement), and to add a 3rd “component” oriented Powered Program for “Compute” to address the use case that seemed to be a sticking point for some key stakeholders, namely the lack of Swift code in a Computing context (e.g. Nebula, Dreamhost, and others).  
>  
> My view is that by following the “storage” precedent, which is an existing “component” Powered Program with qualifiers in the naming rights to educate the market, we are operating under the existing framework for licenses to address the case without having to rush into a “compatible” type program that doesn’t require any code and is API only.  While I do think a “compatible” program for APIs only is likely in the future, I personally would prefer not to rush into it *if* we can address it via this addition of a 3rd “Powered Program”.  For one thing, our test coverage may not yet be high enough to have full confidence in assuring it really is “compatible” by testing alone.  The code piece adds a level or assurance that we’re not going to let end users down.
>  
> Regarding the “Compute Powered Program” that is proposed, one thing we may want to consider is adding something like “If your compute product or service does enable object storage as a service, you must enable the object storage capabilities" (read: pass the API tests but not include the code).  This deviates a bit from the Storage Powered Program precedent so I was hesitant to include it in the proposal, however it does actually mirror the implementation of the cases we were trying to address (e.g. Nebula, Dreamhost) so it might be a shame to not give them (you) credit for having the APIs on top of an alternate back end, which is unquestionably a benefit for interop.  And at the same time, if someone has no object storage as a service at all, we don’t force it on them.  The proposed framework actually doesn’t make this decision per se it says Defcore would determine the appropriate subset of capabilities relevant to “compute” so maybe we could go this route under the proposed Compute Powered Program in the table I put together (see link: https://docs.google.com/a/collierclan.net/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit <https://docs.google.com/a/collierclan.net/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit> )
>  
> [auld] If I understand this correctly, I don’t think this is acceptable. Here is why I say this: I am a vendor without object store and am using the “Compute Powered Program,” then I add CEPH object store, VIOLATION, I can no longer use the “Compute Powered Program?” This does not work. I need to be able to add capabilities on top of whatever mark program I am using.
>  
> Thanks,
>  
> Will

Based on the discussions we’ve had, I don’t think that is the intent. The “Compute Powered Program” is not meant to be “I only use OpenStack compute and nothing else.” Anything additional should be fine. We were looking at this program to address either “I run OpenStack compute with no object store” or “I run OpenStack compute with Ceph/other” 
>  
> Regarding the point that several have raised that an “OpenStack Powered Storage” program is object storage specific and doesn’t allow for something like a Cinder or Manila, I would just say that we ought to consider that in the future. I see no reason not to.  However, for getting us through this very important evolution that we are on the cusp of, which in my mind is a huge leap forward from the status quo we are operating under every day until we make a change, I’d suggest we table that for a future cycle or two.  Certainly for Manlia which is not integrated.  There’s nothing inherent in the framework that would prevent it.
>  
> In some important ways we haven’t really iterated in 4 years on the basic requirements, and so I for one am very eager to take the very thoughtful work defcore has done, map it to existing concepts into this framework with a few tweaks based on the last board meeting, and implement the hell out of it.  
>  
> We are so close!  Let’s do this!
>  
> Mark
>  
>  
>  
>  
>  
>  
>  
> On Oct 1, 2014, at 7:13 PM, Simon Anderson <simon at dreamhost.com <mailto:simon at dreamhost.com>> wrote:
>  
> Mark, on first pass, I see the merit of the Program approach and detail you have described. I'd also like to hear thoughts on Tim's question.
> 
> 
> Best,
> Simon
>  
> On Wed, Oct 1, 2014 at 10:59 AM, Mark Collier <mark at openstack.org <mailto:mark at openstack.org>> wrote:
> Background:
> 
> On a day to day basis, Foundation employees manage the various trademark license Programs (working with our trademark attorneys as needed). A “Program” provides a license for use of the trademarks in commercial contexts, executed between a company in the ecosystem and the Foundation, specific to a product or service. Note: There are multiple Programs (e.g. “OpenStack Powered”, “OpenStack Powered Storage”, “OpenStack Training”).
> 
> A Program typically includes access to a particular commercial-use logo (e.g. “OpenStack Powered”) and some ability to use the word “OpenStack” in the product name and marketing collateral (this is known as the “wordmark” in legalese). A signed contract is required, and there are technical requirements to qualify which include API Capabilities inclusion of specific upstream code (a la Designated Sections).
> 
> Now that we’re nearing the end of the initial DefCore  committee work for Havana, the Board felt it was a good time for the Foundation staff to look at how we might map the DefCore Capabilities and Designated Code to existing or new licensing Programs. Jonathan and I are working on a proposal for the October 20th Board Meeting and want as much input as possible prior.
> 
> This mapping will give everyone another level of understanding regarding how the DefCore components will play out in the market under such Programs, and ultimately give the Board something that they’re confident voting for to move this to implementation phase soon.
> 
> Note that while the Board DID approve the Havana Capabilities in the July Board meeting, they did not approve the proposed update in the September Board meeting, citing various concerns, including the status of Swift and a lack of clarity about how the requirements would play out with our trademark licensees. I believe that by illustrating the different Programs that we would expect to implement with respect to the DefCore work, along with some tweaks to the Designated Sections themselves, we can all get on the same page. We are very close.
> 
> What you’ll see is in practice it’s not an either/or thing with Swift because we have more than one Program to address different markets and choices. Multiple Programs is not a new concept.
> 
> For the purposes of this email I’m going to focus on the “OpenStack Powered” Programs, summarize the requirements and benefits today, then suggest a way that we could map the DefCore output to the two existing programs in a practical way, while adding a third program to address a specific use case. All without creating any more logos.  
> 
> I believe this proposal can address the many different stakeholders' input to date, the incredible work of DefCore, TC and community input, while keeping true to our goal of improving interoperability.
> 
> Note: I strongly advise you check the Google Doc version because a table is a lot easier to follow: 
> https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing <https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing>
> 
> “OpenStack Powered” Programs today:
> 1) Program Name: OpenStack Powered
>          Requirements: Nova and Swift code included, Nova and Swift APIs exposed
>          Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines
> 2) Program Name: OpenStack Powered Storage 
>          Requirements: Swift code included and Swift APIs exposed
>          Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack Storage” in product name within guidelines
> •     Note: Has more restrictive rights, such a requirement to include “Storage” qualifier in product marketing
> 
> Future Programs mapped to DefCore
> 1) Program Name: OpenStack Powered Platform
> •    Requirements: All Capabilities required by Defcore, All Designated Sections from Defcore, Pass Tests
>         Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines — has broadest rights to use the name, such a “ACME OpenStack” for a distro and “ACME OpenStack Cloud” for a public cloud service
> 2) Program Name: OpenStack Powered Storage
>         Requirements: All object storage specific Capabilities from Defcore, all Swift specific Designated Sections from Defcore, Pass Tests
>         Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines.
>         Note: Has more restrictive rights, such as requirement to include “Storage” qualifier in product marketing
> 
> 3) Program Name: OpenStack Powered Compute
>       Requirements: All compute specific Capabilities from Defcore, all Nova, Glance, Cinder specific Designated Sections from Defcore, Pass Tests
>          Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines
>          Note: Has more restrictive rights, such as requirement to include “Compute” qualifier in product marketing.
> 
> *For implementation, Defcore would need to group subsets of the overall output. For example:
> • Platform - no need to group as this is the superset. Suggest adding Swift Designated Sections for Havana based on input from September, and Keystone in Icehouse/Juno based on user input from Das Kamhout & Tim Bell)
> • Storage - subset focused on Object Storage Capabilities and Designated Sections
> • Compute - subset including the Nova, Glance, Cinder for Havana. Suggest adding others as they are included in future releases (e.g. Keystone)
> 
> All of this is also captured in a Google doc that is frankly more readable due to the table and formatting:
> https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing <https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing>
>  
>  
>  
>  
> On Sep 27, 2014, at 6:09 AM, Rob_Hirschfeld at Dell.com <mailto:Rob_Hirschfeld at Dell.com> wrote:
>  
> To clarify, Mark Collier.  We have a lot of Marks working on marks.
>  
>  <>From: Hirschfeld, Rob 
> Sent: Saturday, September 27, 2014 12:20 AM
> To: Defcore-committee at lists.openstack.org <mailto:Defcore-committee at lists.openstack.org>
> Subject: [OpenStack-DefCore] progress - met w/ Foundation
>  
> DefCore,
>  
> Since we’re time sensitive, I wanted to let you know that I had a working session with the Foundation staff Friday.  Alan and Troy also participated.
>  
> We laid out a some options that Mark will review on the list next week.  I think it was a very positive and productive discussion.  I’m optimistic that we have some good suggestions that will address the concerns raised by the Board.
>  
> Also, I’d like to thank those of you who reached out 1x1 after the last Board meeting.
>  
> Rob
> ______________________________
> Rob Hirschfeld
> Sr. Distinguished Cloud Solution Architect
> Dell | Cloud Edge, Data Center Solutions
> cell +1 512 909-7219 <tel:%2B1%20512%20909-7219> blog robhirschfeld.com <http://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 <mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee <http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee>
>  
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org <mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee <http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee>
>  
>  
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org <mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee <http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141002/1fecfc7c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141002/1fecfc7c/attachment-0001.bin>