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 a rebuild. Michael On Wed, Sep 27, 2017 at 4:05 PM, LIU Yulong <liuyulong...@gmail.com> wrote: > On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann <mriede...@gmail.com> > wrote: > >> 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. >> >> 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 >> above. >> >> 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 >> 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. >> >> 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 >> 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). >> >> 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 [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/%23 >>> openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07 < >>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%2 >>> 3openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07> >>> >>> >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.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 Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators