[OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability

Doug Hellmann doug at doughellmann.com
Fri Sep 12 14:34:39 UTC 2014


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/96497009/attachment.html>


More information about the Defcore-committee mailing list