Open Stack

Folks,

As someone that operated and ran large grids and large private clouds, I
think the defcore needs to be a little bit more segmented and think in
regards of end user service consumption.

Simply putŠ

We should have:

OpenStack Compute
OpenStack Object Storage
OpenStack Block Storage
EtcŠ

Telling an operator that has zero need for Compute (when you just want to
have a Swift API) or Object (when you just want to expose Compute) is not
a really winning execution plan. Operators build what their end users
need, and they don¹t always need the everything.

And in each of these situations the API is really what is the most
important (though I am sure everyone would want to make the point that it
is what is under the API that is valuable.  But focusing on the fact that
end users consume services (APIs), and sometimes don¹t actually need all
of them - I think we could have a more compelling and clear proposal.

-Das




On 9/12/14, 10:05 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:

>
>On Sep 12, 2014, at 11:19 AM, Russell Bryant <rbryant at redhat.com> wrote:
>
>> Signed PGP part
>> 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.
>
>The actual current proposal, if I understand correctly, is to require the
>Swift APIs be provided, but not require the use of Swift¹s code to do so.
>We may be converging on dropping the requirement of the APIs, but I don¹t
>think that¹s settled.
>
>I believe, and Rob please correct me if I misunderstood, that some
>distros would also like to provide an OpenStack product that doesn¹t
>include object storage in any way (neither Swift nor Ceph). I¹m not
>especially inclined to care about that use case, but it¹s out there.
>
>Other than those changes, your summary of the situation matches my
>understanding.
>
>> 
>> 
>> 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.
>
>I don¹t like ³treating Swift that way² either. But I prefer leaving out
>those capabilities for now over requiring its features but allowing
>someone else¹s code to completely replace ours, because waiting leaves an
>opening to address the questions you raise above without allowing a
>toe-in-the-door for another solution to use the trademark without any
>designated Swift code at all. I¹m afraid a capabilities-only solution
>would be far more difficult to undo than just saying that we haven¹t
>completely addressed the issues around object storage yet and we¹ll do
>that during the Icehouse DefCore review.
>
>Just to be clear, then, I support either (a) including capabilities and
>the designated sections identified by the development team or (b) having
>no capabilities or designated sections. I do not support including
>capabilities without an implementation, for *any* project.
>
>Doug
>
>> 
>> --
>> Russell Bryant
>> 
>
>
>_______________________________________________
>Defcore-committee mailing list
>Defcore-committee at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee