On 1 March 2016 at 10:10, Daniel P. Berrange <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
