[openstack-dev] [nova] key_pair update on rebuild (a whole lot of conversations)
clint at fewbar.com
Sat Nov 4 15:51:39 UTC 2017
Excerpts from Ben Nemec's message of 2017-10-03 23:05:49 -0500:
> On 10/03/2017 03:16 PM, Sean Dague wrote:
> > = 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
> Here's an example from my use: I create a Heat stack, then realize I
> deployed some of the instances with the wrong keypair. I'd rather not
> tear down the entire stack just to fix that, and being able to change
> keys on rebuild would allow me to avoid doing so. I can rebuild a
> Heat-owned instance without causing any trouble, but I can't re-create it.
> I don't know how common this is, but it's definitely something that has
> happened to me in the past.
Sorry but this is an argument to use Heat more, but rebuild is totally
In heat if you change the keypair and update the stack, it will create a new
one with the right keypair and delete the old instance (or you can make it use
rebuild, a feature I believe I developed actually). The updated IPs will be
rolled out to all resources that reference that instance's IP. If you have wait
conditions which depend on this instance, Heat will wait until they are
re-triggered before deleting the old instance. This is literally why Heat is a
cool thing, because it lets you use the cloud the way the cloud was intended to
If you use rebuild, while it is rebuilding, your service is unavailable. If you
use create/wait/delete you have a chance to automate the transition from the
old to new instance.
> > 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
More information about the OpenStack-dev