Open Stack

+1


On September 12, 2014 3:34:42 PM Doug Hellmann <doug at doughellmann.com> wrote:

>
> On Sep 12, 2014, at 9:55 AM, Mark Collier <mark at openstack.org> wrote:
>
> > I think your reasoning is sound, provided we don't make it harder to 
> follow through on "phase 2" of your proposal in icehouse by conceding the 
> removal of a requirement that is intended to be quickly re-added.
> >
> That’s a fair point. I understood the intent of the DefCore process to be 
> to start small and slowly add to the set of capabilities for subsequent 
> releases, and adding object storage capabilities and Swift designated 
> sections seems to fit within that process.
>
> > Inertia being a thing that can cause such unintended consequences.
> >
> Indeed, if we think there will be a problem adding Swift later, either to a 
> single core trademark or using a separate “OpenStack Object Storage” 
> trademark, or in some other way that the developer community, distros, 
> deployers, and other parties can all stand behind, then I would have to 
> revert to my original stance and support the TC assertion that we should 
> not have designated sections and should be including everything from the 
> beginning. I don’t think that’s the situation, though, and I appreciate the 
> desire to start from a small core and iterate precisely to reduce the 
> unintended consequences of making big decisions quickly.
>
> > Openstack is software, which we as a community create (though heroic 
> efforts which I can't claim credit for myself! But admire, encourage, and 
> support all that much more as a beneficiary of those efforts).
> >
> > OpenStack is an OpenSource Cloud Computing platform that meets the needs 
> of public and private clouds regardless of size, by being simple to 
> implement and massively scalable.
> >
> > Our mission to produce it.
> >
> > I always find out mission statement a handy reminder when trying to make 
> such weighty decisions.
> > https://wiki.openstack.org/wiki/Main_Page
> >
> > (Note I took the poetic license to change "will meet" to "meets" now that 
> we are 4 years in and the largest banks in the world run it.  Whether we've 
> yet achieved 'simple to implement' or 'massively scalable' is an exercise 
> left to the reader.)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On September 12, 2014 2:38:44 PM Doug Hellmann <doug at doughellmann.com> wrote:
> >
> >> The point I have been trying to make is that because our community 
> creates code and not standards, we should not simply trademark an API 
> without including the implementation. For Swift, that means leaving the 
> capabilities out entirely for Havana because we are, for better or worse, 
> leaving the code out entirely. The net effect would be to say that your 
> OpenStack cloud or distribution does not need to include object storage at 
> all, or you can include an object storage system other than Swift without 
> applying the OpenStack trademark to it. That seems to be what at least some 
> of the distributors and deployers want, and seems like a reasonable 
> compromise until we can decide on whether multiple trademark designations 
> solve the problem in a different way.
> >>
> >> If we take this route, we will need to look at the non-designated 
> sections of code for all of the projects to ensure they do not represent 
> the entire implementation of any of the capabilities (I think probably not, 
> but I haven’t audited the list myself).
> >>
> >> I hope we can re-evaluate Swift when we look at the Icehouse version of 
> DefCore, because I would prefer to see all of our integrated projects 
> included in core, but moving ahead without object storage is a better 
> solution than requiring an API and essentially allowing someone to use our 
> name on their code.
> >>
> >> Doug
> >>
> >> On Sep 11, 2014, at 5:44 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:
> >>
> >>> I don't see that symmetry, but I'm still +1 for the discussion with the 
> board.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Sep 11, 2014, at 2:23 PM, "Rochelle.RochelleGrober" 
> <rochelle.grober at huawei.com> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> It makes so much sense once the symmetry was pointed out:
> >>>> If there are no required capabilities, then there is no designated code.
> >>>> If there is no designated code, then there are no required capabilities.
> >>>>
> >>>> --Rocky
> >>>>
> >>>> From: Auld, Will [mailto:will.auld at intel.com]
> >>>> Sent: Thursday, September 11, 2014 1:49 PM
> >>>> To: Rob_Hirschfeld at Dell.com; Defcore-committee at lists.openstack.org
> >>>> Subject: Re: [OpenStack-DefCore] Results from Community Meetings > 
> discussion/+1 about reconsidering Havana Swift as a core capability
> >>>>
> >>>> +1
> >>>>
> >>>> From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com]
> >>>> Sent: Thursday, September 11, 2014 1:35 PM
> >>>> To: Defcore-committee at lists.openstack.org
> >>>> Subject: [OpenStack-DefCore] Results from Community Meetings > 
> discussion/+1 about reconsidering Havana Swift as a core capability
> >>>>
> >>>> DefCore,
> >>>>
> >>>> We just completed our two community meetings.  Community attendance 
> was light but the dialogs where good.
> >>>>
> >>>> I am still working to get input from the PTLs against the designated 
> sections; however, I do not think that we are blocked at this point with 
> the following consideration: Swift capabilities should not be considered 
> core for Havana.
> >>>>
> >>>> I have gotten significant and consistent feedback that the two Swift 
> capabilities should not be included in Havana Core.  This has come from 
> multiple sources, a variety of interests, and different reasons were given.
> >>>>
> >>>> The final straw came today during community review of Swift when the 
> point was made (by Doug Hellman) that if there are no designated sections 
> that having required capabilities does not make sense.
> >>>>
> >>>> While people arrive at this conclusion in different ways, I am 
> confident in saying that community consensus is to reconsider Swift core 
> capabilities.
> >>>>
> >>>> I’d like your opinion (and/or +1) on presenting this to the board on 
> Thursday _before_ discussing the details of designated sections and process 
> flow.  I believe this change will greatly simplify the discussion and allow 
> us to proceed with the DefCore process and results.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Rob
> >>>> ______________________________
> >>>> Rob Hirschfeld
> >>>> Dell, Sr. Distinguished Cloud Solution Architect
> >>>> 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
> >>> _______________________________________________
> >>> Defcore-committee mailing list
> >>> Defcore-committee at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> >>
> >> _______________________________________________
> >> 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/20140912/bfd5a9f4/attachment-0001.html>