Open Stack

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?

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