Open Stack

On Thu, Mar 03, 2016 at 09:09:03AM -0600, Sam Matzek wrote:
> On Wed, Mar 2, 2016 at 8:25 PM, Adam Young <ayoung at redhat.com> wrote:
> > On 02/29/2016 01:49 PM, Andrew Laski wrote:
> >>
> >>
> >> On Mon, Feb 29, 2016, at 01:18 PM, Dan Smith wrote:
> >>>>
> >>>> Forgive my ignorance or for playing devil's advocate, but wouldn't the
> >>>> main difference between notifications and hooks be that notifications
> >>>> are asynchronous and hooks aren't?
> >>>
> >>> The main difference is that notifications are external and intended to
> >>> be stable (especially with the versioned notifications effort). The
> >>> hooks are internal and depend wholly on internal data structures.
> >>>
> >>>> In the case of how Rdo was using it,
> >>>> they are adding things to the injected_files list before the instance is
> >>>> created in the compute API.  You couldn't do that with notifications as
> >>>> far as I know.
> >>>
> >>> Nope, definitely not, but I see that as a good thing. Injecting files
> >>> like that is likely to be very fragile and I think mostly regarded as
> >>> substantially less desirable than the alternatives, regardless of how it
> >>> happens.
> >>>
> >>> I think that Laski's point was that the most useful and least dangerous
> >>> thing that hooks can be used for is the use case that is much better
> >>> served by notifications.
> >
> >
> > I did the original proof-of-concept for this prior to the impl using the
> > hooks, just by modifying the metadata.
> >
> > http://adam.younglogic.com/2013/09/register-vm-freeipa/
> >
> > That works for a CLI based approach, but not for auto-registering VMs
> > created from the WebUI, and also only works if the user crafts the Metadata
> > properly.  It was not a secure approach.
> >
> > What we need is a way to be able to generate a secret and share that between
> > the new VM and the enrolling server.  The call does not strictly have to be
> > synchronous.  The enrolling server can wait if the VM is not up, and the VM
> > can wait if the enrolling server does not have the secret when the VM is
> > ready to enroll.
> >
> > We had discussed having a seperate service listen to notifications on the
> > bus and inject the data necessary into the IdM server.  The hooks were a
> > much better solution.
> >
> > I had seriously thought about using the Keystone token as the symmetric
> > shared secret.  It is a horrible solution, but so are all the rest.
> >
> > There is no security on the message bus at the moment, and until we get
> > some, we can't put a secret on the bus.
> >
> > So, don't deprecate until you have a solution.  All you will be doing is
> > putting people in a tight spot where they will have to fork the code base,
> > and that is downright antisocial.
> >
> > Let's plan this out in the Newton Summit and have a plan moving forward.
> 
> Deprecate isn't the same as remove unless I'm missing something on how
> this works.  I think we want to deprecate it to discourage further
> use, to gather current use cases, and to drive approved specs for
> those use cases.   Hooks should not be removed from tree until we have
> the replacements in tree.

Yes & no. We're not committing to supporting every single thing people
do via hooks today. We're saying that we want people to use notifications
primarily as a way to trigger async execution of hooks outside of nova.
Notifications already exist, but we're lacking an official way to trigger
scripts based off the receipt of a notification. So once that's done we
will have an official replacement available, and we'll consider removing
the hooks mechanism at this point. This will certainly /not/ cover all
possible use cases that hooks are used for today, and that is by design,
since we're explicitly not wanting people to be able to arbitrarily
change nova functionality.

We will however consider requests to add more data fields to notifications
if some key info is missing. Also if there are things that can't be done
via async notifications, we'll consider specs to add explicit features to
achieve a similar goal in nova. That doesn't mean we're going to accept
every request, sumply that we will evaluate them on merit, as we would
with any other Nova feature. Whether we wait for all these potential
feature requests to be implemented before we remove hooks is an open
question. I think it'll depend on the scope of the proposed features and
their importance to the Nova ecosystem, vs other features we have to deal
with implementing. IOW this will be a case by case decision, and we're
not going to wait an abitrarily long time for people to propose replaement
features before deleting hooks.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|