On Feb 3, 2015, at 6:19 AM, Sean Dague <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
