Open Stack

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.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.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/20170927/bed59411/attachment.html>