Open Stack

Mark, thanks for the further detailed and thoughtful reply. I believe this
works for all the Compute use cases in production and/or contemplated that
I have heard. I think this framework works, and agree we should move on it
at the next Board meeting. With further comments/input from the community
of course, plus further definition of the core capabilities and designated
sections required for the Compute Powered mark.


Best,
Simon

On Thu, Oct 2, 2014 at 6:36 AM, Mark Collier <mark at openstack.org> wrote:

> 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
>  )
>
> 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> 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> 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
>>
>> “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
>>
>>
>>
>>
>> On Sep 27, 2014, at 6:09 AM, 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
>> *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 *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: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141002/961210bd/attachment-0001.html>