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

Tom Fifield tom at openstack.org
Fri Aug 15 02:41:51 UTC 2014


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




More information about the Defcore-committee mailing list