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 point.
* 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.
* Easy to use, only one API.
Until someone says we should also do it for the other APIs, as noted above.
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 issue.
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.
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.
* 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).
* 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.
* 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.
* 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.
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
<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
Thanks for at starting this discussion in the mailing list and
summarizing the concerns with both approaches.
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
