On Mon, Feb 29, 2016, at 12:53 PM, Rob Crittenden wrote: > 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.
This is something we can and should address if there is useful information missing from notifications. > > 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 __________________________________________________________________________ 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
