<div dir="ltr">One thing I'd like to explore is what the functional difference between a rebuild and a delete / create cycle is. With a rebuild you get to keep your IP I suppose, but that could also be true of floating IPs for a delete / create as well.<div><br></div><div>Operationally, why would I want to inject a new keypair? The scenario I can think of is that there's data in that instance that I want, and I've lost the keypair somehow. Unless that data is on an ephemeral, its gone if we do a rebuild.</div><div><br></div><div>Michael</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 27, 2017 at 4:05 PM, LIU Yulong <span dir="ltr"><<a href="mailto:liuyulong.xa@gmail.com" target="_blank">liuyulong.xa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Sep 27, 2017 at 10:29 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-">On 9/23/2017 8:58 AM, LIU Yulong wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi nova developers,<br>
<br>
This mail is proposed to reconsider the key pair resetting of instance. The nova queens PTG discuss is here: <a href="https://etherpad.openstack.org/p/nova-ptg-queens" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/nova-ptg-queens</a> <<a href="https://etherpad.openstack.org/p/nova-ptg-queens" rel="noreferrer" target="_blank">https://etherpad.openstack.or<wbr>g/p/nova-ptg-queens</a>> L498. And there are now two proposals.<br>
<br>
1. SPEC 1: <a href="https://review.openstack.org/#/c/375221/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/375221/</a> <<a href="https://review.openstack.org/#/c/375221/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/375221/</a>> started by me (liuyulong) since sep 2016.<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
<br>
This spec will allow setting the new key_name for the instance during rebuild API. That’s a very simple and well-understood approach:<br>
<br></span>
* Make consistent with rebuild API properties, such as name, imageRef,<br>
metadata, adminPass etc.<br>
* Rebuild API is something like `recreating`, this is the right way to<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
do key pair updating. For keypair-login-only VM, this is the key point.<br></span>
* This does not involve to other APIs like reboot/unshelve etc.<br>
</blockquote>
<br>
This was one of the issues I brought up in IRC, is that if we just implemented this for the rebuild API, then someone could also ask that we do it for things like reboot, cold migrate/resize, unshelve, etc. Anything that involves re-creating the guest.<br>
<br></blockquote></span><div>IMHO, rebuild has its own meaning is that we are going to recreate a VM. So those inputs such as name, key, password should have a chance to be reset in this `rebuild` interface. Unlike reboot, cold migrate/resize, unshelve, those actions does not have such potential implication. If anything else involved, you are expanding those actions (reboot, cold migrate/resize, unshelve).</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Easy to use, only one API.<br>
</blockquote>
<br>
Until someone says we should also do it for the other APIs, as noted above.<br>
<br></blockquote></span><div>This could not be acceptable. Other APIs does not have such `recreating` background. For rebuild, you are going to renew an instance, so those params for instance creation should have chance to be reset.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
By the way, here is the patch (<a href="https://review.openstack.org/#/c/379128/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/379128/</a> <<a href="https://review.openstack.org/#/c/379128/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/379128/</a>>) which has implemented this spec. And it stays there more than one year too.<br>
</blockquote>
<br>
It's been open because the spec was never approved. Just a procedural issue.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. SPEC 2 : <a href="https://review.openstack.org/#/c/506552/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/506552/</a> <<a href="https://review.openstack.org/#/c/506552/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/506552/</a>> propose by Kevin_zheng.<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
<br>
This spec supposed to add a new updating API for one instance’s key pair. This one has one foreseeable advantage for this is to do instance running key injection.<br>
<br>
But it may cause some issues:<br>
<br></span>
* This approach needs to update the instance key pair first (one step,<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
API call). And then do a reboot/rebuild or any actions causing the<br>
vm restart (second step, another API call). Firstly, this is waste,<br>
it use two API calls. Secondly, if updating key pair was done, and<br>
the reboot was not. That may result an inconsistent between instance<br>
DB key pair and guest VM inside key. Cloud user may confused to<br>
choose which key should be used to login.<br>
</span></blockquote>
<br>
1. I don't think multiple API calls is a problem. Any GUI or orchestration tool can stitch these APIs together for what appears to be a single operation for the end user. Furthermore, with multiple options about what to do after the instance.key_name is updated, something like a GUI could present the user with the option to picking if they want to reboot or rebuild after the key is updated.<br>
<br></blockquote></span><div>We provided a discontinuous API, so we should take responsibilities for it. This inconsistent between instance DB key pair and guest VM inside can stay there. So GUI or orchestration tool can not be a reasonable support. More API calls may cause more problems. What if the GUI or orchestration tool user/developer forget the second API? What if the first API failed, should the retry all the APIs? Which key should be used to login if first API succeed and the second not succeed/not response? What if the second API failed? They confused again and again.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. An orchestrator or GUI would make sure that both APIs are called. For a user that is updating the key_name, they should realize they need to make another API call to enable it. This would all be in the API reference documentation, CLI help, etc, that anyone doing this should read and understand.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* For the second step (reboot), there is a strong constraint is that<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
cloud-init config needs to be set to running-per-booting. But if a<br>
cloud platform all images are set cloud-init to per-deployment. In<br>
order to achieve this new API goal, the entire cloud platform images<br>
need updating. This will cause a huge upgrading work for entire<br>
cloud platform images. They need to change all the images cloud-init<br>
config from running-per-deployment to running-every-boot. But that<br>
still can not solve the inconsistent between DB keypair and<br>
guest-key. For instance, if the running VM is based on a<br>
running-once-cloud-init image: 1. create image from this VM; 2.<br>
change the keypair of the new VM; 3. reboot still can not work<br>
because of the old config of per-deployment-running.<br>
</span></blockquote>
<br>
This is per-cloud configuration, and as such it should be documented with the cloud documentation. I can't say what is more "normal" for OpenStack clouds to be doing with cloud-init here, that would be a good question for the operators community (I've cross posted to the ops ML).<br>
<br></blockquote></span><div>This upgrading issue could make a result that `rebuild` become the only way to apply new key to VM.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* For another second step (rebuild), if they have to rebuild, or<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
rebuild is the only one way to deployment new key, we are going back<br>
to rebuild SPEC 1. Two steps for keypair updating are not good. Why<br>
don’t directly using SPEC 1?<br>
</span></blockquote>
<br>
Because of the points made above, which are if I can simply reboot my instance to use the new keypair rather than rebuild it, that is much better. Plus then it doesn't just limit us to rebuild, but the new key could also be used after unshelving or cold migrating the instance.<br>
<br></blockquote></span><div>This the point we are going to expand functionalities of reboot/migrate/unshelving? Quoting the point you mentioned above "someone may say we should also do it for the other APIs, like restart, evacuate, start ? " What about password/name/image/flavor/use<wbr>r-data, one day these can also be reset in reboot/migrate/unshelving/rest<wbr>art/evacuate/start API ?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Another perspective to think about this is that SPEC 2 is expanding<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
the functionality of reboot. What about one day user want to change<br>
password/name/personality at a reboot?<br>
</span></blockquote>
<br>
Kevin's spec does not propose any change to the reboot (or rebuild) APIs.<br>
<br></blockquote></span><div>Yes, but if you change the key first, reboot may become the key step for applying the key to VM. Reboot does not just reboot a VM, it takes a new responsibility. For rebuild, SPEC 1 makes sense.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Cloud user may still have questions: why key pair can not be updated<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
during rebuilding ? Why name/image/personality can?<br></span>
* If new API does not supporting running injection, the DB keypair and<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
guest keypair are inconsistent if cloud user forget a rebuiding,<br>
reboot, unshelving API call.<br>
</span></blockquote>
<br>
This is the same as the point made above, which I replied to, but anyone calling the native APIs should be reading the docs and understanding what they do. If they don't want that level of detail, use a GUI or orchestration tool.<br>
<br></blockquote></span><div>Discontinuous API results such concern. APIs are fixed, users are variable.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-">
<br>
<br>
In conclusion, IMHO SPEC 1 is the reasonable way to set key pair for rebuild API. It’s simple and easy.<br>
<br>
SPEC 2 can be used for future running key injection. And it is still a way for reboot API to deploy the new key. But the its disadvantages are as stated above.<br>
<br>
<br>
There already has some discuss [1] about this with Matt and Kevin.<br>
<br>
Sincerely hope to receive your opinion. Feel free to ping me at IRC openstack-nova, my nick is liuyulong. Thank you very much.<br>
<br>
<br>
<br></span>
[1] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org<wbr>/irclogs/%23openstack-nova/%23<wbr>openstack-nova.2017-09-22.log.<wbr>html#t2017-09-22T14:05:07</a> <<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07" rel="noreferrer" target="_blank">http://eavesdrop.openstack.or<wbr>g/irclogs/%23openstack-nova/%2<wbr>3openstack-nova.2017-09-22.log<wbr>.html#t2017-09-22T14:05:07</a>><span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-"><br>
<br>
<br>
<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>
<br>
</span></blockquote>
<br>
Thanks for at starting this discussion in the mailing list and summarizing the concerns with both approaches.<span class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt</font></span><div class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-HOEnZb"><div class="m_-3868648176550157455gmail-m_-5487696005088118754gmail-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></span></div><br></div></div>
<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>