[openstack-dev] [nova] reset key pair during rebuilding
mikal at stillhq.com
Wed Sep 27 08:23:08 UTC 2017
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.
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
On Wed, Sep 27, 2017 at 4:05 PM, LIU Yulong <liuyulong.xa at gmail.com> wrote:
> On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann <mriedemos at gmail.com>
>> On 9/23/2017 8:58 AM, LIU Yulong 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.openstack.org
>>> /p/nova-ptg-queens <https://etherpad.openstack.org/p/nova-ptg-queens> L498.
>>> And there are now two proposals.
>>> 1. SPEC 1: https://review.openstack.org/#/c/375221/ <
>>> 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
>>> * This does not involve to other APIs like reboot/unshelve etc.
>> 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.
>> 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).
>> * Easy to use, only one API.
>> Until someone says we should also do it for the other APIs, as noted
>> 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.
>>> By the way, here is the patch (https://review.openstack.org/#/c/379128/
>>> <https://review.openstack.org/#/c/379128/>) which has implemented this
>>> spec. And it stays there more than one year too.
>> It's been open because the spec was never approved. Just a procedural
>>> 2. SPEC 2 : https://review.openstack.org/#/c/506552/ <
>>> 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.
>> 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.
>> 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.
>> 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
>> * 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.
>> 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).
>> This upgrading issue could make a result that `rebuild` become the only
> way to apply new key to VM.
>> * 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?
>> 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.
>> 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/user-data, one day these
> can also be reset in reboot/migrate/unshelving/restart/evacuate/start API
>> * 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?
>> Kevin's spec does not propose any change to the reboot (or rebuild) APIs.
>> 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.
>> * 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.
>> 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.
>> Discontinuous API results such concern. APIs are fixed, users
> are variable.
>>> 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  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.
>>>  http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23
>>> openstack-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.op
>> Thanks for at starting this discussion in the mailing list and
>> summarizing the concerns with both approaches.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev