Daniel P. Berrange wrote:
> On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:

>> Deprecation isn't a one-way street really, nova-network was deprecated for a
>> couple of releases and then undeprecated and opened up again for feature
>> development (at least for a short while until the migration to neutron is
>> sorted out and implemented).
> Nova-network was prematurely deprecated as the alternative was not fully
> ready. That's a prime example of why we should not be deprecating EC2
> right now either.
> Deprecation is a mechanism by which you inform users that they should
> stop using the current functionality and switch to $NEW-THING as the
> replacement. In the case of nova-network they could not switch because
> neutron did not offer feature parity at the time we were asking them
> to switch (nor did it have an upgrade path for that matter). Likewise
> in the case of the EC2 API, the alternative is not ready for users to
> actually switch to at a production quality level.
> What we actually trying to tell users is that we think the out of tree
> EC2 implementation is the long term strategic direction of the EC2
> support with Nova, and that the current in tree impl is not being actively
> developed. That's a sensible thing to tell our users, but deprecation is
> the wrong mechanism for this. It is a task best suited for release notes.
> Keep deprecation available as a mechanism for telling users that the time
> has come for them to actively switch their deployments to the new impl.

I'm with Daniel on that one. We shouldn't "deprecate" until we are 100%
sure that the replacement is up to the task and that strategy is solid.

Today, we are just figuring out the strategy between the mainline EC2
support and the separated EC2 support repository, and we have some
promised resources to work on the issue. We have been there before (a
few times), and if we had deprecated the EC2 support on that promise
back then, we would have put ourselves in an odd corner. Today is not
really the best moment to "deprecate". Announcing the proposed strategy,
however, is good information to send to our users.

Thierry Carrez (ttx)

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to