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