Hi, FYI, we are going to use the existing PUT /servers/{server_uuid} API, adding the 'key_name' field.
On Sat, Sep 23, 2017 at 9:58 PM, LIU Yulong <liuyulong...@gmail.com> wrote: > Hi nova developers, > > This mail is proposed to reconsider the key pair resetting of instance. > The nova queens PTG discuss is here: https://etherpad.opensta > ck.org/p/nova-ptg-queens L498. And there are now two proposals. > > 1. SPEC 1: https://review.openstack.org/#/c/375221/ started by me > (liuyulong) since sep 2016. > > This spec will allow setting the new key_name for the instance during > rebuild API. That’s a very simple and well-understood approach: > > - Make consistent with rebuild API properties, such as name, imageRef, > metadata, adminPass etc. > - 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. > - This does not involve to other APIs like reboot/unshelve etc. > - Easy to use, only one API. > > By the way, here is the patch (https://review.openstack.org/#/c/379128/) > which has implemented this spec. And it stays there more than one year too. > > 2. SPEC 2 : https://review.openstack.org/#/c/506552/ propose by > Kevin_zheng. > > 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. > > But it may cause some issues: > > - 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. > - 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. > - 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? > - 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? > - Cloud user may still have questions: why key pair can not be updated > during rebuilding ? Why name/image/personality can? > - 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. > > > In conclusion, IMHO SPEC 1 is the reasonable way to set key pair for > rebuild API. It’s simple and easy. > > 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. > > > There already has some discuss [1] about this with Matt and Kevin. > > Sincerely hope to receive your opinion. Feel free to ping me at IRC > openstack-nova, my nick is liuyulong. Thank you very much. > > > > [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack- > nova.2017-09-22.log.html#t2017-09-22T14:05:07 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev