Open Stack

On 1 March 2016 at 10:10, Daniel P. Berrange <berrange at redhat.com> 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.

We did discuss the road to creating a very similar mechanism at the
last design summit, although the notes from that session are a little
cryptic:
https://etherpad.openstack.org/p/mitaka-nova-service-users

Roughly it was a per instance keystone token that would then give you
you access to Barbican, or similar.

Thanks,
johnthetubaguy