Open Stack

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.

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