Open Stack

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140815/2b1e3205/attachment-0001.html>