Open Stack

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


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