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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ 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