[OpenStack-DefCore] Please review, results from Designated Sections review w/ recommendations. +1s needed

Tom Fifield tom at openstack.org
Mon Aug 18 04:58:45 UTC 2014


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-openstacksummitatl2014-
>> 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-rev
>> >> > >> ie
>> >> > >> w)
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> These are also discussed on my blog at
>> >> > >> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-revi
>> >> > >> 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/defcore-c
>> >> > >>> om
>> >> > >>> mit
>> >> > >>> te
>> >> > >>> e
>> >> > >>
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > Defcore-committee mailing list
>> >> > > Defcore-committee at lists.openstack.org
>> >>
>> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-com
>> >> > > mi
>> >> > > tte
>> >> > > e
>> >> > >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Defcore-committee mailing list
>> >> > Defcore-committee at lists.openstack.org
>> >>
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-commi
>> >> > tt
>> >> > ee
>> >>
>> >> _______________________________________________
>> >> Defcore-committee mailing list
>> >> Defcore-committee at lists.openstack.org
>> >>
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committ
>> >> ee
> 




More information about the Defcore-committee mailing list