Open Stack

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: defcore-page1.png
Type: image/png
Size: 78267 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/17689eb1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defcore-page2.png
Type: image/png
Size: 47982 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/17689eb1/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defcore-page3.png
Type: image/png
Size: 33201 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/17689eb1/attachment-0005.png>