[openstack-dev] [nova] key_pair update on rebuild (a whole lot of conversations)
mikal at stillhq.com
Wed Oct 4 00:48:05 UTC 2017
I think new-keypair-on-rebuild makes sense for some forms of key rotation
as well. For example, I've worked with a big data ironic customer who uses
rebuild to deploy new OS images onto their ironic managed machines.
Presumably if they wanted to do a keypair rotation they'd do it in a very
So yes, I think you've reached the right conclusion here. Thanks for your
On Wed, Oct 4, 2017 at 9:06 AM, Matt Riedemann <mriedemos at gmail.com> wrote:
> On 10/3/2017 3:16 PM, Sean Dague wrote:
>> There is currently a spec up for being able to specify a new key_pair
>> name during the rebuild operation in Nova -
>> For those not completely familiar with Nova operations, rebuild triggers
>> the "reset this vm to initial state" by throwing out all the disks, and
>> rebuilding them from the initial glance images. It does however keep the
>> IP address and device models when you do that. So it's useful for
>> ephemeral but repeating workloads, where you'd rather not have the
>> network information change out from under you.
> We also talked quite a bit about rebuild with volume-backed instances
> today, and the fact the root disk isn't replaced during rebuild in that
> case, for which there are many reported bugs...
>> The spec is a little vague about when this becomes really useful,
>> because this will not save you from "I lost my private key, and I have
>> important data on that disk". Because the disk is destroyed. That's the
>> point of rebuild. We once added this preserve_ephemeral flag to rebuild
>> for trippleo on ironic, but it's so nasty we've scoped it to only work
>> with ironic backends. Ephemeral should mean ephemeral.
>> Rebuild bypasses the scheduler. A rebuilt server stays on the same host
>> as it was before, which means the operation has a good chance of being
>> faster than a DELETE + CREATE, as the image cache on that host should
>> already have the base image for you instance.
> It also means no chances for NoValidHost or resource claim failures.
>> A bunch of data was collected today in a lot of different IRC channels
>> (#openstack-nova, #openstack-infra, #openstack-operators).
>> = OpenStack Operators =
>> mnaser said that for their customers this would be useful. Keys get lost
>> often, but keeping the IP is actually valuable. They would also like this.
>> penick said that for their existing environment, they have a workflow
>> where this would be useful. But they are moving away from using nova for
>> key distribution because in Nova keys are user owned, which actually
>> works poorly given that everything else is project owned. So they are
>> building something to do key distribution after boot in the guest not
>> using nova's metadata.
>> Lots of people said they didn't use nova's keypair interfaces, they just
>> did it all in config management after the fact.
>> = Also on reboot? =
>> Because the reason people said they wanted it was: "I lost my private
>> key", the question at PTG was "does that mean you want it on reboot?"
>> But as we dive through the constraints of that, people that build "pet"
>> VMs typically delete or disable cloud-init (or similar systems) after
>> first boot. Without that kind of agent, this isn't going to work anyway.
>> So also on reboot seems very fragile and unuseful.
>> = Infra =
>> We asked the infra team if this is useful to them, the answer was no.
>> What would be useful them is if keypairs could be updated. They use a
>> symbolic name for a keypair but want to do regular key rotation. Right
>> now they do this by deleting then recreating keypairs, but that does
>> mean there is a window where there is no keypair with that name, so
>> server creates fail.
>> It is agreed that something supporting key rotation in the future would
>> be handy, that's not in this scope.
>> = Barbican =
>> In the tradition of making a simple fix a generic one, it does look like
>> there is a longer term part of this where Nova should really be able to
>> specify a Barbican resource url for a key so that things like rotation
>> could be dealt with in a system that specializes in that. It also would
>> address the very weird oddity of user vs. project scoping.
>> That's a bigger more nebulous thing. Other folks would need to be
>> engaged on that one.
>> = Where I think we are? =
>> I think with all this data we're at the following:
>> Q: Should we add this to rebuild
>> A: Yes, probably - after some enhancement to the spec *
>> * - we really should have much better use cases about the situations it
>> is expected to be used in. We spend a lot of time 2 and 3 years out
>> trying to figure out how anyone would ever use a feature, and adding
>> another one without this doesn't seem good
>> Q: should this also be on reboot?
>> A: NO - it would be too fragile
>> I also think figuring out a way to get Nova out of the key storage
>> business (which it really shouldn't be in) would be good. So if anyone
>> wants to tackle Nova using Barbican for keys, that would be ++. Rebuild
>> doesn't wait on that, but Barbican urls for keys seems like a much
>> better world to be in.
> Sean, thanks for summarizing the various discussions had today. I've also
> included the operators list on this.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev