<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 18, 2016 at 9: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:0 0 0 .8ex;border-left:1px #ccc solid;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><br>
<br>
And we're in the process in Nova of doing some spring cleaning and<br>
deprecating the proxies to other services -<br>
<a href="https://review.openstack.org/#/c/312209/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/312209/</a><br>
<br>
At some point in the future after deprecation the proxy code is going to<br>
stop working. Either accidentally, because we're not going to test or<br>
fix this forever (and we aren't going to track upstream API changes to<br>
the proxy targets), or intentionally when we decide to delete it to make<br>
it easier to address core features and bugs that everyone wants addressed.<br>
<br>
However, the world moves forward slowly. Consider the following scenario.<br>
<br>
We delete nova-net & the network proxy entirely in Peru (a not entirely<br>
unrealistic idea). At that release there are a bunch of people just<br>
getting around to Newton. Their deployments allow all these things to<br>
happen which are going to 100% break when they upgrade, and people are<br>
writing more and more OpenStack software every cycle.<br>
<br>
How do we signal to users this kind of deprecation? Can we give sites<br>
tools to help prevent new software being written to deprecated (and<br>
scheduled for deletion) APIs?<br>
<br>
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>
<br>
In the Nova case the kinds of things ending up in this bucket are going<br>
to be interfaces that people *really* shouldn't be using any more. Many<br>
of them data back to when OpenStack was only 2 projects, and the concept<br>
of splitting out function wasn't really thought about (note: we're<br>
getting ahead of this one for the 'placement' rest API, so it won't have<br>
any of these issues). At some point this house cleaning was going to<br>
have to happen, and now seems to be the time to do get it rolling.<br>
<br>
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>
<span class="HOEnZb"><font color="#888888"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">I like the idea of a switch in the config file. To Dean's point, would it also be worth considering a "list-deprecated-calls" that could give him a list without having to do the roundtrip every time? That might not actually solve anything for him, but perhaps something along those lines would help?</div><br></div></div>