Open Stack

On Feb 3, 2015, at 6:19 AM, Sean Dague <sean at dague.net> wrote:

> On 02/03/2015 08:57 AM, Thierry Carrez wrote:
>> Jesse Pretorius wrote:
>>> I think that perhaps something that shouldn't be lost site of is that
>>> the users using the EC2 API are using it as-is. The only commitment that
>>> needs to be made is to maintain the functionality that's already there,
>>> rather than attempt to keep it up to scratch with newer functionality
>>> that's come into EC2.
>>> 
>>> The stackforge project can perhaps be the incubator for the development
>>> of a full replacement which is more up-to-date and interacts more like a
>>> translator. Once it's matured enough that the users want to use it
>>> instead of the old EC2 API in-tree, then perhaps deprecation is the
>>> right option.
>>> 
>>> Between now and then, I must say that I agree with Sean - perhaps the
>>> best strategy would be to make it clear somehow that the EC2 API isn't a
>>> fully tested or up-to-date API.
>> 
>> Right, there are several dimensions in the issue we are discussing.
>> 
>> - I completely agree we should communicate clearly the status of the
>> in-tree EC2 API to our users.
>> 
>> - Deprecation is a mechanism by which we communicate to our users that
>> they need to evolve their current usage of OpenStack. It should not be
>> used lightly, and it should be a reliable announcement. In the past we
>> deprecated things based on a promised replacement plan that never
>> happened, and we had to un-deprecate. I would very much prefer if we
>> didn't do that ever again, because it's training users to ignore our
>> deprecation announcements. That is what I meant in my earlier email. We
>> /can/ deprecate, but only when we are 99.9% sure we will follow up on that.
>> 
>> - The supposed "35% of our users" are actually more 44% of the user
>> survey respondents replying "yes" when asked if they ever used the EC2
>> API in their deployment of OpenStack. Given that it's far from being up
>> to date or from behaving fully like the current Amazon EC2 API, it's
>> fair to say that those users are probably more interested in keeping the
>> current OpenStack EC2 API support as-is, than they are interested in a
>> new project that will actually make it better and/or different.
> 
> All of which is fair, however there is actually no such thing as
> "keeping support as-is". The EC2 API is the equivalent of parts of Nova
> + Neutron + Cinder + Keystone + Swift. However the whole thing is
> implemented in Nova. Nova, for instances, has a terrible s3 object store
> in tree to make any of this work (so that the EC2 API doesn't actually
> depend on Swift). As the projects drift away and change their semantics,
> and bump their APIs keeping the same support is real work, that's not
> getting done.

This is a bit unfair. This code path is only used for ec2_register_image
which I think is almost completely unused even by ec2 these days. Also,
it can use any s3 object store (for example swift with swift3 in front).

Vish

> 
> It will become different over time regardless, the real question is if
> it gets different worse or different better.
> 
>> - Given legal uncertainty about closed APIs it might make *legal* sense
>> to remove it from Nova or at least mark it deprecated and freeze it
>> until that removal can happen. Projects in Stackforge are, by
>> definition, not OpenStack projects, and therefore do not carry the same
>> risk.
>> 
> 
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev