On Wed, May 18, 2016 at 9:20 AM, Sean Dague <s...@dague.net> wrote:
> nova-net is now deprecated - https://review.openstack.org/#/c/310539/ > > And we're in the process in Nova of doing some spring cleaning and > deprecating the proxies to other services - > https://review.openstack.org/#/c/312209/ > > At some point in the future after deprecation the proxy code is going to > stop working. Either accidentally, because we're not going to test or > fix this forever (and we aren't going to track upstream API changes to > the proxy targets), or intentionally when we decide to delete it to make > it easier to address core features and bugs that everyone wants addressed. > > However, the world moves forward slowly. Consider the following scenario. > > We delete nova-net & the network proxy entirely in Peru (a not entirely > unrealistic idea). At that release there are a bunch of people just > getting around to Newton. Their deployments allow all these things to > happen which are going to 100% break when they upgrade, and people are > writing more and more OpenStack software every cycle. > > How do we signal to users this kind of deprecation? Can we give sites > tools to help prevent new software being written to deprecated (and > scheduled for deletion) APIs? > > 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. > > In the Nova case the kinds of things ending up in this bucket are going > to be interfaces that people *really* shouldn't be using any more. Many > of them data back to when OpenStack was only 2 projects, and the concept > of splitting out function wasn't really thought about (note: we're > getting ahead of this one for the 'placement' rest API, so it won't have > any of these issues). At some point this house cleaning was going to > have to happen, and now seems to be the time to do get it rolling. > > 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. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > 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?
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators