On Wed, Sep 27, 2017 at 4:23 PM, Michael Still <[email protected]> wrote:
> 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. > > The neutron port which was used by the VM does not changed, so the floating IP will not need to be recreate. > 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. > > "The old VM was using a wrong image, I want to change it. Bad things happened in the VM, I want reinstall the OS. Oh, I lost my old private key. I can reset the image, but I can't login it." -- A cloud user's whisper. Rebuild is try to recreate, a new param added to the existing rebuild API meets the renew purpose. Michael > > > On Wed, Sep 27, 2017 at 4:05 PM, LIU Yulong <[email protected]> > wrote: > >> On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann <[email protected]> >> 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: [email protected] >>>> 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: [email protected] >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
