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