Andrew Laski wrote: > > > On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote: >>> In our continued quest on being more explicit about plug points it feels >>> like we should other document the interface (which means creating >>> stability on the hook parameters) or we should deprecate this construct >>> as part of a bygone era. >>> >>> I lean on deprecation because it feels like a thing we don't really want >>> to support going forward, but I can go either way. >> >> Deprecate and remove, please. We've been removing these sorts of things >> over time, and nova hooks have been ignored in that process. But really, >> making them more rigid is going to get in the way over time, trying to >> continue to honor an interface that codifies internals at a certain >> point in time, and leaving them as-is will just continue to generate >> issues like the quoted bug. >> >> I don't "lean" on deprecation, I feel strongly that these should go away. > > I've worked on a deployment that uses them heavily and would be impacted > by their removal. They are a very convenient place to put code that > should run based on Nova events but I have yet to see a usage that > couldn't have been implemented by having a service listen to > notifications and run that same code. However there is no service that > does this. So the only argument I can see for keeping them is that it's > more convenient to put that code into Nova rather than implement > something that listens for notifications. And that's not a convincing > argument to me.
The ability to inject files on a per-VM basis is one thing that would be missing. Right now decisions can be made inside the hook using attributes of the VM to decide whether and what to inject, including files generated inside the hook itself. I won't argue that the API is nice, it isn't, but I'd prefer a replace then deprecate model instead. I'm not entirely sure that the notifications contain all the same information as is available now in the hooks. rob > So I agree with moving forward on deprecation and think that > notifications provide a suitable replacement for the functionality > provided. > > >> >> --Dan >> >> __________________________________________________________________________ >> 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 > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
