<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 18, 2016 at 10:20 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">nova-net is now deprecated - <a href="https://review.openstack.org/#/c/310539/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/310539/</a></blockquote><div><br></div><div>Woot! Now to make it not-the-default in DevStack...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
One idea was a "big red switch" in the format of a config option<br>
``disable_deprecated_apis=True`` (defaults to False). Which would set<br>
all deprecated APIs to 404 routes.<br>
<br>
One of the nice ideas here is this would allow some API servers to have<br>
this set, and others not. So users could point to the "clean" API<br>
server, figure out that they will break, but the default API server<br>
would still support these deprecated APIs. Or, conversely, the default<br>
could be the clean API server, and a legacy API server endpoint could be<br>
provided for projects that really needed it that included these<br>
deprecated things for now. Either way it would allow some site assisted<br>
transition. And be something like the -Werror flag in gcc.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Feedback on this idea would be welcomed. We're going to deprecate the<br>
proxy APIs regardless, however disable_deprecated_apis is it's own idea<br>
and consequences, and we really want feedback before pushing forward on<br>
this.<br></blockquote></div><div><br></div><div>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.</div><div><br></div><div>dt</div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>