Open Stack

On Wed, Sep 27, 2017 at 4:23 PM, Michael Still <mikal at stillhq.com> 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 <liuyulong.xa at gmail.com>
> wrote:
>
>> On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann <mriedemos at 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-request at 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-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-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/20170928/2572c6eb/attachment-0001.html>