Open Stack

On Wed, May 18, 2016 at 10:20 AM, Sean Dague <sean at dague.net> wrote:

> nova-net is now deprecated - https://review.openstack.org/#/c/310539/


Woot! Now to make it not-the-default in DevStack...


> One idea was a "big red switch" in the format of a config option
> ``disable_deprecated_apis=True`` (defaults to False). Which would set
> all deprecated APIs to 404 routes.
>
> One of the nice ideas here is this would allow some API servers to have
> this set, and others not. So users could point to the "clean" API
> server, figure out that they will break, but the default API server
> would still support these deprecated APIs. Or, conversely, the default
> could be the clean API server, and a legacy API server endpoint could be
> provided for projects that really needed it that included these
> deprecated things for now. Either way it would allow some site assisted
> transition. And be something like the -Werror flag in gcc.
>

With an app-dev/end-user hat on, I really like the idea of there being some
switch I can control (alternate endpoint or service catalog?
 account/project toggle? don't know exactly what yet) to do testing with
the deprecated APIs disabled.

This is really a problem of migrating/prompting the client developers to do
the right thing.  Often times they (including myself) respond faster to
their users and not the upstream projects, so giving the users the ability
to test and provide feedback would be huge here.

With my OSC hat on, I need to still support those APIs for a couple of
years at least, so I would love to have a way to discover that those APIs
have been disabled without requiring a round trip to get a 404.  This seems
like a useful thing for the '/' route version information when no
'/capabilities'-like endpoint is available.

OSC already does detect when the network service type is available and just
uses it whenever possible, I have not yet completely thought through if
this is a good enough general solution, ie, what we want clients to do that
must live in both worlds for a time.

Feedback on this idea would be welcomed. We're going to deprecate the
> proxy APIs regardless, however disable_deprecated_apis is it's own idea
> and consequences, and we really want feedback before pushing forward on
> this.
>

Operators need something to be able to help this process along, the config
option seems really clean to me.  That leaves how to enable the users to
make use of that choice.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160518/daef55fc/attachment.html>