Open Stack

Thanks for taking the time Rob, much appreciated. Certainly wasn't
trying to be "Bill Clinton" there! I'm talking about only case number 1.

>> 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"?
> 
> 1)      object store (not swift code) passes all the swift capabilities
>> YES, they can use the trademark
> 
> If we change the recommendation to include designated sections for swift
> then case 1 becomes a NO.

What I am seeking to confirm is any additional steps this cloud provider
would have to perform, other than "passing the capabilities".

My guess is that they would have no obligation to (for example):
* inform the user that the object storage is not swift
* publish swift as a line item in the "versions of openstack components"
list that Joshua reminded us about (eg "swift: not used")


Am I correct in that?


Regards,


Tom





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