<div dir="ltr">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 similar way.<div><br></div><div>So yes, I think you've reached the right conclusion here. Thanks for your work Sean.</div><div><br></div><div>Michael</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 4, 2017 at 9:06 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/3/2017 3:16 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is currently a spec up for being able to specify a new key_pair<br>
name during the rebuild operation in Nova -<br>
<a href="https://review.openstack.org/#/c/375221/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/375221/</a><br>
<br>
For those not completely familiar with Nova operations, rebuild triggers<br>
the "reset this vm to initial state" by throwing out all the disks, and<br>
rebuilding them from the initial glance images. It does however keep the<br>
IP address and device models when you do that. So it's useful for<br>
ephemeral but repeating workloads, where you'd rather not have the<br>
network information change out from under you.<br>
</blockquote>
<br></span>
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...<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The spec is a little vague about when this becomes really useful,<br>
because this will not save you from "I lost my private key, and I have<br>
important data on that disk". Because the disk is destroyed. That's the<br>
point of rebuild. We once added this preserve_ephemeral flag to rebuild<br>
for trippleo on ironic, but it's so nasty we've scoped it to only work<br>
with ironic backends. Ephemeral should mean ephemeral.<br>
<br>
Rebuild bypasses the scheduler. A rebuilt server stays on the same host<br>
as it was before, which means the operation has a good chance of being<br>
faster than a DELETE + CREATE, as the image cache on that host should<br>
already have the base image for you instance.<br>
</blockquote>
<br></span>
It also means no chances for NoValidHost or resource claim failures.<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A bunch of data was collected today in a lot of different IRC channels<br>
(#openstack-nova, #openstack-infra, #openstack-operators).<br>
<br>
= OpenStack Operators =<br>
<br>
mnaser said that for their customers this would be useful. Keys get lost<br>
often, but keeping the IP is actually valuable. They would also like this.<br>
<br>
penick said that for their existing environment, they have a workflow<br>
where this would be useful. But they are moving away from using nova for<br>
key distribution because in Nova keys are user owned, which actually<br>
works poorly given that everything else is project owned. So they are<br>
building something to do key distribution after boot in the guest not<br>
using nova's metadata.<br>
<br>
Lots of people said they didn't use nova's keypair interfaces, they just<br>
did it all in config management after the fact.<br>
<br>
= Also on reboot? =<br>
<br>
Because the reason people said they wanted it was: "I lost my private<br>
key", the question at PTG was "does that mean you want it on reboot?"<br>
<br>
But as we dive through the constraints of that, people that build "pet"<br>
VMs typically delete or disable cloud-init (or similar systems) after<br>
first boot. Without that kind of agent, this isn't going to work anyway.<br>
<br>
So also on reboot seems very fragile and unuseful.<br>
<br>
= Infra =<br>
<br>
We asked the infra team if this is useful to them, the answer was no.<br>
What would be useful them is if keypairs could be updated. They use a<br>
symbolic name for a keypair but want to do regular key rotation. Right<br>
now they do this by deleting then recreating keypairs, but that does<br>
mean there is a window where there is no keypair with that name, so<br>
server creates fail.<br>
<br>
It is agreed that something supporting key rotation in the future would<br>
be handy, that's not in this scope.<br>
<br>
= Barbican =<br>
<br>
In the tradition of making a simple fix a generic one, it does look like<br>
there is a longer term part of this where Nova should really be able to<br>
specify a Barbican resource url for a key so that things like rotation<br>
could be dealt with in a system that specializes in that. It also would<br>
address the very weird oddity of user vs. project scoping.<br>
<br>
That's a bigger more nebulous thing. Other folks would need to be<br>
engaged on that one.<br>
<br>
<br>
= Where I think we are? =<br>
<br>
I think with all this data we're at the following:<br>
<br>
Q: Should we add this to rebuild<br>
A: Yes, probably - after some enhancement to the spec *<br>
<br>
* - we really should have much better use cases about the situations it<br>
is expected to be used in. We spend a lot of time 2 and 3 years out<br>
trying to figure out how anyone would ever use a feature, and adding<br>
another one without this doesn't seem good<br>
<br>
Q: should this also be on reboot?<br>
A: NO - it would be too fragile<br>
<br>
<br>
I also think figuring out a way to get Nova out of the key storage<br>
business (which it really shouldn't be in) would be good. So if anyone<br>
wants to tackle Nova using Barbican for keys, that would be ++. Rebuild<br>
doesn't wait on that, but Barbican urls for keys seems like a much<br>
better world to be in.<br>
<br>
        -Sean<br>
<br>
</blockquote>
<br></div></div>
Sean, thanks for summarizing the various discussions had today. I've also included the operators list on this.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>