[openstack-dev] [nova] nova hooks - document & test or deprecate?
andrew at lascii.com
Mon Feb 29 18:33:55 UTC 2016
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.
> > 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev