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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators