Open Stack

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.

One other way to do this that I haven't seen mentioned in the thread
yet, is create your own middleware code and put it in the wgsi
pipeline in Nova api-paste.  For the shared secret / injected file
case you could process the create server request after keystone but
before Nova API proper, do your synchronous call outs, and then add
your files to the injected files part of the Nova request body.

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