[openstack-dev] [nova] nova hooks - document & test or deprecate?
Rob Crittenden
rcritten at redhat.com
Tue Mar 1 18:53:18 UTC 2016
Daniel P. Berrange wrote:
> On Mon, Feb 29, 2016 at 12:36:03PM -0700, Rich Megginson wrote:
>> On 02/29/2016 12:19 PM, Chris Friesen wrote:
>>> On 02/29/2016 12:22 PM, Daniel P. Berrange wrote:
>>>
>>>> There's three core scenarios for hooks
>>>>
>>>> 1. Modifying some aspect of the Nova operation
>>>> 2. Triggering an external action synchronously to some Nova operation
>>>> 3. Triggering an external action asynchronously to some Nova operation
>>>>
>>>> The Rdo example is falling in scenario 1 since it is modifying the
>>>> injected files. I think this is is absolutely the kind of thing
>>>> we should explicitly *never* support. When external code can arbitrarily
>>>> modify some aspect of Nova operation we're in totally unchartered
>>>> territory as to the behaviour of Nova. To support that we'd need to
>>>> provide a stable internal API which is just not something we want to
>>>> tie ourselves into. I don't know just what the Rdo example is trying
>>>> to achieve, but whatever it is, it should be via some supportable API
>>>> and not a hook.,
>>>>
>>>> Scenaris 2 and 3 are both valid to consider. Using the notifications
>>>> system gets as an asynchronous trigger mechanism, which is probably
>>>> fine for many scenarios. The big question is whether there's a
>>>> compelling need for scenario two, where the external action blocks
>>>> execution of the Nova operation until it has completed its hook.
>>>
>>> Even in the case of scenario two it is possible in some cases to use a
>>> proxy to intercept the HTTP request, take action, and then forward it or
>>> reject it as appropriate.
>>>
>>> I think the real question is whether there's a need to trigger an external
>>> action synchronously from down in the guts of the nova code.
>>
>> The hooks do the following: https://github.com/rcritten/rdo-vm-factory/blob/use-centos/rdo-ipa-nova/novahooks.py#L271
>>
>> We need to generate a token (ipaotp) and call ipa host-add with that token
>> _before_ the new machine has a chance to call ipa-client-install. We have
>> to guarantee that the client cannot call ipa-client-install until we get
>> back the response from ipa that the host has been added with the token.
>> Additionally, we store the token in an injected_file in the new machine, so
>> the file can be removed as soon as possible. We tried storing the token in
>> the VM metadata, but there is apparently no way to delete it? Can the
>> machine do
>>
>> curl -XDELETE http://168.254.169.254/openstack/latest/metadata?key=value ?
>>
>> Using the build_instance.pre hook in Nova makes this simple and
>> straightforward. It's also relatively painless to use the network_info.post
>> hook to handle the floating ip address assignment.
>>
>> Is it possible to do the above using notifications without jumping through
>> too many hoops?
>
> So from a high level POV, you are trying to generate a security token
> which will be provided to the guest OS before it is booted.
>
> I think that is a pretty clearly useful feature, and something that
> should really be officially integrated into Nova as a concept rather
> than done behind nova's back as a hook.
Note that the reason the file was injected the way it was is so that
Nova would have no idea there even is a token. We didn't want someone
later peeking at the metadata, or a notification, to get the token.
rob
More information about the OpenStack-dev
mailing list