Open Stack

Ok, I'll give it a shot.  I think we have a "Bill Clinton" issue with the word "is" here because it depends on what you mean by "is."  For DefCore, we define a project primarily by capabilities defined by the API.

> 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"?

There are a few options based on the current recommendation:


1)      object store (not swift code) passes all the swift capabilities > YES, they can use the trademark

2)      object store (not swift code) does not pass the swift capabilities > NO, they cannot use the trademark

3)      object store (uses swift code) passes all the swift capabilities > YES, they can use the trademark

4)      object store (uses swift code) does not pass the swift capabilities > NO, they cannot use the trademark

If we change the recommendation to include designated sections for swift then case 1 becomes a NO.

Better?

> -----Original Message-----
> From: Tom Fifield [mailto:tom at openstack.org]
> Sent: Sunday, August 17, 2014 9:59 PM
> To: Hirschfeld, Rob; joshua at pistoncloud.com
> Cc: defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Please review, results from
> Designated Sections review w/ recommendations. +1s needed
>
> Sorry to hear that Rob!
>
> Perhaps a direct reply to this example can assist?
>
>
> > >> > >>> 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 18/08/14 12:44, Rob_Hirschfeld at Dell.com wrote:
> > Tom,
> >
> >
> >
> > I'm still missing it. I thought we'd been pretty specific in the
> > examples. Perhaps we should setup a call.
> >
> >
> >
> > Really, users don't see designated sections at all. It's all about
> > which code the vendor is required to include in their product.
> > That's not something the user would see at all and, in many cases,
> > there's no practical way to enforce it.
> >
> >
> >
> > For the capabilities, we have refstack. Users would be able to
> > duplicate the test suite run against their OpenStack product and
> > prove that it meets the core requirements.
> >
> >
> >
> > Does that help?
> >
> >> -----Original Message-----
> >> From: Tom Fifield [mailto:tom at openstack.org]
> >> Sent: Sunday, August 17, 2014 9:38 PM
> >> To: Joshua McKenty; Hirschfeld, Rob
> >> Cc:
> >> Subject: Re: [OpenStack-DefCore] Please review, results from
> >> Designated Sections review w/ recommendations. +1s needed
> >>
> >> Cool - that's more like what I'm getting at - practical aspects of
> >> the trademark license requirements as related to the below
> >> 'designated sections', as they apply to what end users actually see.
> >>
> >> So far I haven't seen anything remotely close to this written down,
> >> and I believe it can really help with general understanding and comment.
> >>
> >>
> >> Regards,
> >>
> >>
> >> Tom
> >>
> >>
> >> On 16/08/14 02:33, Joshua McKenty wrote:
> >> > The other trademark license requirements (to publish the versions
> >> > of the components being used, etc) still apply as well.
> >> >
> >> > Sent from my iPhone
> >> >
> >> > On Aug 14, 2014, at 11:09 PM,
> >> > > wrote:
> >> >
> >> >> Tom,
> >> >>
> >> >>
> >> >>
> >> >> I thought we had some pretty specific examples for public and
> >> >> private clouds with references to specific projects. Remember,
> >> >> the mark is all or nothing at this point. Vendors must pass the
> >> >> required tests and use the required code to use the mark. There
> >> >> is no subset or partial mark at this point.
> >> >>
> >> >>
> >> >>
> >> >> Rob
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: Tom Fifield [mailto:tom at openstack.org]
> >> >> > Sent: Thursday, August 14, 2014 7:44 PM
> >> >> > To: defcore-committee at lists.openstack.org
> >> >>
> >> >> > Subject: Re: [OpenStack-DefCore] Please review, results from
> >> >> > Designated Sections review w/ recommendations. +1s needed
> >> >> >
> >> >> > 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-openstacksummitatl201
> >> >> > >> 4-
> >> cor
> >> >> > >> e-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-
> >> >> > >> re
> >> >> > >> v
> >> >> > >> ie
> >> >> > >> w)
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> These are also discussed on my blog at
> >> >> > >> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-r
> >> >> > >> ev
> >> >> > >> i
> >> >> > >> ew
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> 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/defcor
> >> >> > >>> e-
> >> >> > >>> c
> >> >> > >>> om
> >> >> > >>> mit
> >> >> > >>> te
> >> >> > >>> e
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > > _______________________________________________
> >> >> > > Defcore-committee mailing list
> >> >> > > Defcore-committee at lists.openstack.org
> >> >>
> >> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-
> >> >> > > co
> >> >> > > m
> >> >> > > mi
> >> >> > > tte
> >> >> > > e
> >> >> > >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Defcore-committee mailing list
> >> >> > Defcore-committee at lists.openstack.org
> >> >>
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-co
> >> >> > mm
> >> >> > i
> >> >> > tt
> >> >> > ee
> >> >>
> >> >> _______________________________________________
> >> >> Defcore-committee mailing list
> >> >> Defcore-committee at lists.openstack.org
> >> >>
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-comm
> >> >> it
> >> >> t
> >> >> ee
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140818/c4af6cdc/attachment-0001.html>