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.
Yep. My experience with them was things like updating an external cache
on create/delete or calling out to a DNS provider to remove a reverse
DNS entry on instance delete. Things that could easily be handled with
notifications, and use cases that I think we should continue to support
by improving notifications if necessary.
So, if file injection (and any other internals-mangling that other
people may use them for) is not a reason to keep hooks, and if
notifications are the proper way to trigger on things happening, then
there's no reason to keep hooks.
--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
