<div dir="ltr">
<p class="gmail-p1">Hi nova developers,</p><p class="gmail-p1">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"><span class="gmail-s1">https://etherpad.openstack.org/p/nova-ptg-queens</span></a> L498. And there are now two proposals.<br>
</p><p class="gmail-p1">1. SPEC 1: <a href="https://review.openstack.org/#/c/375221/"><span class="gmail-s2">https://review.openstack.org/#/c/375221/</span></a> started by me (liuyulong) since sep 2016.</p><p class="gmail-p1"> This spec will allow setting the new key_name for the instance during rebuild API. That’s a very simple and well-understood approach:</p><ul class="gmail-ul1">
<li class="gmail-li1">Make consistent with rebuild API properties, such as name, imageRef, metadata, adminPass etc.</li>
<li class="gmail-li1">Rebuild API is something like `recreating`, this is the right way to do key pair updating. For keypair-login-only VM, this is the key point.</li>
<li class="gmail-li1">This does not involve to other APIs like reboot/unshelve etc.</li>
<li class="gmail-li1">Easy to use, only one API.</li>
</ul><p class="gmail-p1">By the way, here is the patch (<a href="https://review.openstack.org/#/c/379128/"><span class="gmail-s1">https://review.openstack.org/#/c/379128/</span></a>) which has implemented this spec. And it stays there more than one year too.</p><p class="gmail-p2"><span class="gmail-s3">2. SPEC 2 : <a href="https://review.openstack.org/#/c/506552/"><span class="gmail-s1">https://review.openstack.org/#/c/506552/</span></a> propose by Kevin_zheng.</span></p><p class="gmail-p1">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.</p><p class="gmail-p1">But it may cause some issues:</p><ul class="gmail-ul1">
<li class="gmail-li1">This approach needs to update the instance key pair first (one step, API call). And then do a reboot/rebuild or any actions causing the vm restart (second step, another API call). Firstly, this is waste, it use two API calls. Secondly, if updating key pair was done, and the reboot was not. That may result an inconsistent between instance DB key pair and guest VM inside key. Cloud user may confused to choose which key should be used to login.</li>
<li class="gmail-li1">For the second step (reboot), there is a strong constraint is that cloud-init config needs to be set to running-per-booting. But if a cloud platform all images are set cloud-init to per-deployment. In order to achieve this new API goal, the entire cloud platform images need updating. This will cause a huge upgrading work for entire cloud platform images. They need to change all the images cloud-init config from running-per-deployment to running-every-boot. But that still can not solve the inconsistent between DB keypair and guest-key. For instance, if the running VM is based on a running-once-cloud-init image: 1. create image from this VM; 2. change the keypair of the new VM; 3. reboot still can not work because of the old config of per-deployment-running.</li>
<li class="gmail-li1">For another second step (rebuild), if they have to rebuild, or rebuild is the only one way to deployment new key, we are going back to rebuild SPEC 1. Two steps for keypair updating are not good. Why don’t directly using SPEC 1?</li>
<li class="gmail-li1">Another perspective to think about this is that SPEC 2 is expanding the functionality of reboot. What about one day user want to change password/name/personality at a reboot?</li>
<li class="gmail-li1">Cloud user may still have questions: why key pair can not be updated during rebuilding ? Why name/image/personality can?</li>
<li class="gmail-li1">If new API does not supporting running injection, the DB keypair and guest keypair are inconsistent if cloud user forget a rebuiding, reboot, unshelving API call.</li>
</ul><p class="gmail-p3"><br></p><p class="gmail-p1">In conclusion, IMHO SPEC 1 is the reasonable way to set key pair for rebuild API. It’s simple and easy.</p><p class="gmail-p1">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.</p><p class="gmail-p3"><br></p><p class="gmail-p1">There already has some discuss [1] about this with Matt and Kevin.</p><p class="gmail-p1">Sincerely hope to receive your opinion. Feel free to ping me at IRC openstack-nova, my nick is liuyulong. Thank you very much.</p><p class="gmail-p1"><br></p><p class="gmail-p3"><br></p><p class="gmail-p1">
</p><p class="gmail-p2"><span class="gmail-s3">[1] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07"><span class="gmail-s2">http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07</span></a></span></p></div>