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

Mark McLoughlin markmc at redhat.com
Wed Sep 17 08:18:15 UTC 2014


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.

My train of thought is:

  - Would you expect some object storage capabilities in an "OpenStack
    Powered" cloud or product? I think so.

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

    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.

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.




More information about the Defcore-committee mailing list