Open Stack

On Sep 17, 2014, at 4:18 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2014-09-12 at 11:19 -0400, Russell Bryant wrote:
>> On 09/12/2014 10:56 AM, John Dickinson wrote:
>>> 
>>> On Sep 12, 2014, at 7:34 AM, 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.
>>> 
>>> Unfortunately, at this point I have no idea what the objections are
>>> currently (other than "the PTL and Piston, DreamHost, and IBM don't
>>> agree"--and frankly I'm not sure what decision that's referring
>>> to), and there is nothing that has been presented as steps to for
>>> future inclusion or specific concerns to address.
>>> 
>>> So I too am concerned by inertia of removing a capability "intended
>>> to be quickly re-added" when the current objections are 
>>> undocumented and there is no guidance for the future.
>> 
>> I agree that the objections need to be called out and not danced
>> around.  From my perspective, it seems pretty clear that the issue is:
>> 
>> 1) Some organizations want to provide object storage capabilities in
>> their product and not use Swift (or even any portion of Swift) to do so.
>> 
>> 2) These organizations want to ensure that their choice in #1 does not
>> prevent their ability to use the OpenStack mark.
>> 
>> 3) The proposed resolution to this issue by DefCore is to exclude
>> Swift completely from the requirements around the use of the OpenStack
>> mark.
>> 
>> 
>> Regarding #1, one primary case is the use of Ceph.  It would be nice
>> to respond to this case very directly.  I know it has been discussed,
>> but is it written down?  I'd love to see something (a blog post or
>> similar) that discusses:
>> 
>> - how can ceph be used to back swift today?
>> - if it can't, what work is required to make that possible?
>> - if it's never going to realistically be an option, discuss why
>> 
>> The other case for #1 is some proprietary object store.  The answer to
>> that really is the same as #1.  As long as there is a reasonable way
>> for vendors to back swift with their thing, the objection is no longer
>> reasonable, IMO.
>> 
>> If someone shows up and just really wants to use some other thing
>> instead of Nova, does that mean Nova is kicked out?  I sure hope not.
>> If not, then why treat Swift that way?  If the issue is that backing
>> Swift with your "thing" isn't straight forward like backing Nova with
>> your "thing", then fine.  Let's just lay out the path to get to that
>> point.
> 
> All good points.
> 
> However, to a large extent, I think the board needs to make its decision
> based on what's best for the commercial ecosystem now and into the
> future.

The commercial ecosystem is certainly important. But the contributors to the project are part of that ecosystem.

> 
> My train of thought is:
> 
>  - Would you expect some object storage capabilities in an "OpenStack
>    Powered" cloud or product? I think so.

I think it’s likely, yes.

> 
>  - Are there existing clouds or products which are positive promoters 
>    of OpenStack, engage with the community in good faith and offer an 
>    experience to their users which we think represents our brand
>    well ... but yet do not use Swift to implement their object storage 
>    capabilities?

I’m not sure how we measure involvement. My impression is that some parties are fairly involved, but some are less so (possibly to the point of “not really at all”). I’m sure my impression is biased based on my interactions with them, though.

> 
>    My impression is that there are such clouds and products, but I
>    don't have a great insight into the details and I would really like
>    to hear a lot more specific information about which products we're
>    talking about and what choices they have made.
> 
>  - Is the Swift community and the vendors of those clouds and 
>    products working together to allow Swift to be used to implement 
>    their object storage capabilities, while still respecting the
>    choices (assuming they are valid choices) that lead them to not use
>    Swift initially?
> 
>    My impression is that work is going on, but I don't have a great 
>    handle on the details.

My impression is, and this is just based on a few of the meetings, that some companies want swift to be “pluggable” in a different way than it is because they want to use a different backend but the details are very fuzzy about what exactly that means. I’m not familiar enough with the code to know whether the assertion that “Swift isn’t pluggable (enough)” even makes any sense, so I’ll leave that to others more familiar to comment on. But because there is disagreement there, we should be careful and apply the principle of maintaining a small “core”. It will be easier to add capabilities than remove them.

> 
> In other words, my thinking is that we should keep the object storage
> capabilities, don't add any Swift designated sections for Havana,
> encourage the work that will enable Swift designated sections to be
> added for future releases ... but I don't feel like I've heard the level
> of detail that I need to make a fully informed decision.
> 
> Mark.
>