Open Stack

On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:
> 
> 
> On 1/30/2015 3:16 PM, Soren Hansen wrote:
> >As I've said a couple of times in the past, I think the
> >architecturally sound approach is to keep this inside Nova.
> >
> >The two main reasons are:
> >  * Having multiple frontend API's keeps us honest in terms of
> >separation between the different layers in Nova.
> >  * Having the EC2 API inside Nova ensures the internal data model is
> >rich enough to "feed" the EC2 API. If some field's only use is to
> >enable the EC2 API and the EC2 API is a separate component, it's not
> >hard to imagine it being deprecated as well.
> >
> >I fear that deprecation is a one way street and I would like to ask
> >one more chance to resucitate it in its current home.
> >
> >I could be open to a discussion about putting it into a separate
> >repository, but having it functionally remain in its current place, if
> >that's somehow easier to swallow.
> >
> >
> >Soren Hansen             | http://linux2go.dk/
> >Ubuntu Developer         | http://www.ubuntu.com/
> >OpenStack Developer      | http://www.openstack.org/
> >
> >
> >2015-01-28 20:56 GMT+01:00 Sean Dague <sean at dague.net>:
> >>The following review for Kilo deprecates the EC2 API in Nova -
> >>https://review.openstack.org/#/c/150929/
> >>
> >>There are a number of reasons for this. The EC2 API has been slowly
> >>rotting in the Nova tree, never was highly tested, implements a
> >>substantially older version of what AWS has, and currently can't work
> >>with any recent releases of the boto library (due to implementing
> >>extremely old version of auth). This has given the misunderstanding that
> >>it's a first class supported feature in OpenStack, which it hasn't been
> >>in quite sometime. Deprecating honestly communicates where we stand.
> >>
> >>There is a new stackforge project which is getting some activity now -
> >>https://github.com/stackforge/ec2-api. The intent and hope is that is
> >>the path forward for the portion of the community that wants this
> >>feature, and that efforts will be focused there.
> >>
> >>Comments are welcomed, but we've attempted to get more people engaged to
> >>address these issues over the last 18 months, and never really had
> >>anyone step up. Without some real maintainers of this code in Nova (and
> >>tests somewhere in the community) it's really no longer viable.
> >>
> >>         -Sean
> >>
> >>--
> >>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
> >>
> >
> >__________________________________________________________________________
> >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
> >
> 
> 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.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|