Open Stack

Thanks Mark, this is good to know re how you and the OpenStack attorneys
see the language changing. I agree with the direction being taken to the
policy language, that you set out in your email.


Best,
Simon


On Tue, Aug 19, 2014 at 8:03 AM, Mark Collier <mark at openstack.org> wrote:

> Just to add some additional background information.  Today, if you wish to
> qualify for the OpenStack Powered logo (see attached) as well as other
> associated trademark rights (i.e. how you name your product if it includes
> the word “OpenStack” in it) . You must meet these criteria.  Note that this
> list of requirement is rather old, dating back to a time when we had a LOT
> fewer projects and capabilities, and thus, in my view, the sooner we can
> implement something better, the better, even if that something better isn’t
> perfect (as few things are).
>
> On the substantive questions raised throughout this thread on the right
> policies, I am very interested to hear from users like Tim on what really
> matters wrt interop, since in my mind that’s job #1 of this whole exercise.
>
>
> Current Requirements Language:
> ---------------------
>
> a.  A primary purpose of your product must be to run a functioning
> operational instance of the OpenStack software.
>
> b.  Your product must:
>
> i. upon its launch, include the entirety of the OpenStack Compute (Nova)
> code from either of the latest two releases and associated milestones, and
>
> ii. upon its launch, include the entirety of the OpenStack Object Storage
> (Swift) code from either of the latest two releases and associated
> milestones, and
>
> iii. expose the associated OpenStack APIs published on
> http://www.openstack.org without modification.
>
> c. You must clearly state which OpenStack projects and versions are used
> to set customer expectations, in a way that is conspicuous to customers.
>
> d. As of January 1st, 2012, your product must pass any Faithful
> Implementation Test Suite (FITS) defined by the Technical Committee that
> will be made available on http://www.openstack.org/FITS, to verify that
> you are implementing a sufficiently current and complete version of the
> software (and exposing associated APIs) to ensure compatibility and
> interoperability. Your product will be required to pass the current FITS
> test on an annual basis, which will generally require you to be running
> either of the latest two software releases.
>
> —————--------------------
>
> So today we require you to have 100% of Nova + the Nova APIs.  and 100% of
> Swift + the Swift APIs.  Now one might point out that this lacks some level
> of specificity to be crystal clear, but I think what Rob and team have been
> trying to do over the past few months is to bring a lot more specificity to
> whatever comes next, which is both an ambitious and admirable goal.  Both
> in terms of 1) what APIs we mean specifically 2) what tests we mean you to
> pass specifically associated with those APIs and 3) what code requirements,
> specifically, are required (and looking beyond just Nova and Swift to the
> whole list of possible projects … which are now thought of as
> “capabilities” more so than “projects” to take a more user centric view).
>
> So how will the contract language re: requirements change as defcore, the
> board, and community arrive at a consensus on “what’s next”?  Here’s what i
> expect:
>
>
>    - It is my expectation that A) will stay as-is.  "A primary purpose of
>    your product must be to run a functioning operational instance of the
>    OpenStack software.” We could tweak it but I think it’s pretty clear.
>    - It is my expectation that c) will stay as-is "You must clearly state
>    which OpenStack projects and versions are used to set customer
>    expectations, in a way that is conspicuous to customers.”
>
>
>    - And that everything under b, which deals with capabilities/code/apis
>    today will be re-written to reflect the required capabilities, APIs,
>    and code inclusion once those are approved (note that Icehouse is the first
>    expected enforceable version, as the Havana stuff being discussed today
>     is “advisory” meaning it wouldn’t be a contract requirement). I am
>    working on this language in conjunction with our trademark attorney
>    (with placeholders for the actual things that are in or out, pending a
>    decision there) and will socialize it with the ecosystem and defcore.  We
>    might actually want to take the specificity out of the agreement
>    itself and point instead to a web page where the details are posted, so
>    that we can get this moving faster and not over burden the agreement itself.
>    - My expectation is that d) will be re-written to more accurately
>    reflect the expected testing requirements and mechanisms.  Frankly, if we
>    just put the tests  and steps up on the page OpenStack.org/FITS then
>    I’m not sure how much change this language needs. That said, we should
>    decide if this is still the standard for freshness and re-testing we want
>    to have "Your product will be required to pass the current FITS test
>    on an annual basis, which will generally require you to be running either
>    of the latest two software releases. “
>
>
> The benefit of sticking with as much of the language in D) as possible is
> that it has been in agreements for years, and is thus socialized and
> actually agreed to by many many companies already.  I’m not
> against re-writing it but let’s do so for a good reason.  One thing that
> does not seem to jive with the current reality is the statement that the
> FITS test is “defined by the Technical Committee.  Would it be more
> accurate to say that we are now looking to the Board to define the test?  I
> don’t have a dog in that fight, just wanting to have the agreements reflect
> the direction we’re going, so we’re ready to cut over when it’s time.
>
>
>
>
>
>
>
>
>
>
> On Aug 19, 2014, at 12:50 AM, Tom Fifield <tom at openstack.org> wrote:
>
> I'm pretty much blocked out until the ops meetup is over (say 1st
> September or so) - when is that board meeting again?
>
> but anyway, here's what I'm thinking:
>
> Simple webapp that does away with everything but components, explaining
> the complex bits only in context for what a potential trademark
> applicant is trying to do with components.
>
> so, two parts:
>
> 1) the form (static html) - what is the activity {run a cloud, make a
> storage product etc}, what trademark {powered, compatible, etc}, and
> which components are being used
>
> 2) the result page (a template, filled in by some code based on the form
> selections)
>
> that talks about whether the components they've ticked are enough, and
> also about what they're allowed to do with those components.
> Ideally, each component name would link off to a dedicated page for that
> component explaining the 'designated sections' and required API things.
>
> mockups attached - very, very rough!
>
>
> I'd propose to create this and circulate it so that the community can
> understand the impact of the suggested designated sections before the
> board meeting.
>
>
>
> Regards,
>
>
> Tom
>
> On 15/08/14 14:04, Rob_Hirschfeld at Dell.com wrote:
>
> Tom / Josh,
>
>
>
> We can update the examples; however, I think that we could use some help
> here.  You can I are very close to the material and make assumptions
> about reader knowledge when explaining it.
>
>
>
> It would be helpful to have someone (Tom?) with a fresh perspective take
> a pass at it.
>
>
>
> Rob
>
> -----Original Message-----
> From: Tom Fifield [mailto:tom at openstack.org <tom at openstack.org>]
> Sent: Thursday, August 14, 2014 7:52 PM
> To: Joshua McKenty
> Cc: defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Please review, results from
> Designated Sections review w/ recommendations. +1s needed
>
> All good with me :) Though, I would note the timeframe here is short.
> We obviously want the community to be able to understand the real
> impact of these suggested designated suggestions and comment on them
> well before any board meeting, so revisited sooner the better IMO!
>
>
> Regards,
>
>
> Tom
>
>
> On 15/08/14 10:47, Joshua McKenty wrote:
>
> Tom, those examples we're put together before the trademark was
> changed
>
> by the foundation staff. We may need to revisit those practical concerns.
>
>
> Sent from my iPhone
>
> On Aug 14, 2014, at 7:43 PM, Tom Fifield wrote:
>
> Hit send too soon :) I also didn't find any "practical
> implementation concerns" in those slides - that would also be
> appreciated :)
>
>
> I'm also interested in any practical implementation concerns you
> think can arise based on the below suggestions.
>
> For example, in the case of an "OpenStack Powered" cloud that
> offers an object store that is not swift, would they be
> recommended/required to denote that actually that particular bit
> was
>
> not "Openstack Powered"?
>
>
> I could see that being confusing for users, and my guess is
> there might be some similar cases that should be managed :)
>
>
>
> Regards,
>
>
> Tom
>
> On 15/08/14 10:41, Tom Fifield wrote:
> Hi Rob,
>
> Thanks for the reply :)
>
> I actually find these pretty complicated - is there a chance for
> some simpler ones?
>
>
> Regards,
>
>
> Tom
>
> On 15/08/14 09:59, Rob_Hirschfeld at Dell.com wrote:
> Tom,
>
>
>
> I agree!
>
>
>
> Josh and I did a presentation with examples in ATL
> (http://www.confreaks.com/videos/3695-openstacksummitatl2014-core
> -
>
> v
>
> ia-crowd-sourcing-defcores-tempest-in-a-docker-container-tcup
> ) and I gave an updated version at OSCON
> (http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review
> )
>
>
>
> These are also discussed on my blog at
> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review
>
>
>
> Please let me know if those examples help explain the use of the
> mark better.
>
>
>
> Thanks
>
> -----Original Message-----
> From: Tom Fifield [mailto:tom at openstack.org]
> Sent: Thursday, August 14, 2014 6:14 PM
> To: defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Please review, results from
> Designated Sections review w/ recommendations. +1s needed
>
> Hi Rob,
>
> Can you provide a few example uses of the commercial marks based
> on
>
> below?
>
>
> eg "I can call my cloud "OpenStack Powered" without regard to
> the use of Keystone."
>
>
> I'm also interested in any practical implementation concerns you
> think can arise based on the below suggestions.
>
> For example, in the case of an "OpenStack Powered" cloud that
> offers an object store that is not swift, would they be
> recommended/required to denote that actually that particular bit
> was
>
> not "Openstack Powered"?
>
>
> I could see that being confusing for users, and my guess is
> there might be some similar cases that should be managed :)
>
>
> Regards,
>
>
> Tom
>
> On 15/08/14 04:54, Rob_Hirschfeld at Dell.com wrote:
> DefCore,
>
>
>
> We had a small turn out and very good discussions that were
> able to produce clear guidance for Designated Sections (see
> below). We also reviewed the Havana capabilities from the board
> meeting and the 10 designated sections principles approved by
> email. Finally, we setup a calendar for community review
> leading up to the September Board meeting
>
>
>
> Here are the recommendations:
>
> · Havana Nova is by default designated except scheduler,
> filter, drivers, API extensions and networking.
>
> · Havana Swift has no designated code due to lack of consensus
> (see principles)
>
> · Havana Keystone is not designated.
>
> · Havana Glance designated sections are the API implementation
> code and domain model.
>
> · Havana Cinder designated sections are the API implementation
> code
>
> · Havana Neutron has no designated sections.
>
> · Havana Heat is not a core capability, no position at this time.
>
> · Havana Horizon is not a core capability, no position at this
>
> time.
>
>
> · other projects do not are not core capabilities and are not
> reviewed at this time.
>
>
>
> Please contribute to a discussion or +1
>
>
>
> 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-comm
> it
> tee
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-commit
> te
> e
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committ
> ee
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>
>
> <defcore-page1.png><defcore-page2.png><defcore-page3.png>
> _______________________________________________
>
> 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/20140819/aa7e2680/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack-powered-sample.png
Type: image/png
Size: 39880 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/aa7e2680/attachment-0001.png>