Open Stack

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-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