Open Stack

On Tue, Mar 01, 2016 at 01:53:18PM -0500, Rob Crittenden wrote:
> 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.

That's just security through obscurity

Anyway, if you wish to be able to continue to support your use case,
I'll strongly recommend that you look to propose a mechanism to officially
support provision of tokens to guest OS in Nova. It is pretty clear from
this thread that the hooks mechanism you rely on is going to be deleted
in the future, likely as soon as the Newton release.

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