Open Stack

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.xa at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170925/1a6a51ba/attachment.html>