On 02/29/2016 01:33 PM, Andrew Laski wrote: > > > 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.
100% agreed. I would consider that a priority feature for Newton if it can be enumerated. -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