Open Stack

Russell Bryant wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
I know the discussion has moved on quite a bit since this note on 
Friday, but to help provide the missing information at least from an IBM 
perspective I'll add what we shared with Rob and those at the DefCore 
F2F a month ago:

- IBM is unique in that we *don't* have interest in a proprietary 
implementation of Swift--we are using Swift upstream code. (therefore #1 
doesn't apply to us, and I believe Dreamhost was also in this category)

- IBM does, however, have a market strategy that offers differentiated 
products--one being a compute offering, based on upstream OpenStack 
code, and one being a separate object store product, using Swift 
upstream code and IBM storage capabilities (Elastic Storage, aka GPFS, 
for those who might recognize an older name)

- We (IBM) are planning on validating both offerings against the 
appropriate core tests via Refstack and complying with designated 
section definitions, but from a product marketing perspective everything 
will not be in one integrated OpenStack offering from IBM (although 
there are other solutions and offerings which will include both).

This was our specific feedback to the DefCore process and is somewhat 
tangential to what seems to be the main objection around proprietary 
object stores not using Swift at all.  However, given as the 
conversation has continued it appears that all objections have been 
lumped into an assumption that all "objecting" vendors have a desire to 
not use OpenStack Swift, I thought it might be useful to offer the IBM 
perspective which has nothing to do with using a proprietary replacement 
for Swift.  I can not speak for Dreamhost in any official sense, but my 
understanding was that they had a similar "market offering" 
differentiation, not a non-Swift code use objection.

Thanks,
Phil Estes
>
> 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.
>
> - -- 
> Russell Bryant
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlQTDw4ACgkQFg9ft4s9SAZaRgCgrwSSUKCvF0ky5cMDF79r7XrB
> 3PAAnA7w2cTAWU1Q/WGorb815RU8Uws4
> =0WOl
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>