Re: [openstack-dev] [nova] reset key pair during rebuilding

[LIU Yulong]

On Wed, Sep 27, 2017 at 4:23 PM, Michael Still  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 
> wrote:
>
>> On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann 
>> 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  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/
 ) 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 

Re: [openstack-dev] [nova] reset key pair during rebuilding

[LIU Yulong]

On Wed, Sep 27, 2017 at 5:15 PM, Marcus Furlong  wrote:

> On 27 September 2017 at 09:23, Michael Still  wrote:
> >
> > 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.
>
> This is quite a common scenario - staff member who started the
> instance leaves, and you want to access data on the instance, or
> maintain/debug the service running on the instance.
>
>

I can think of several ways to solve this problem：
1) reset the password by using the admin_pass API (if available)
2) libguestfs the instance dist directly



> Hitherto, I have used direct db calls to update the key, so it would
> be nice if there was an API call to do so.
>
>

These are some tricks for unusual scenarios. Nova API needs to stay robust
and general.



> Cheers,
> Marcus.
> --
> Marcus Furlong
>
> __
> 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 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

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Marcus Furlong]

On 27 September 2017 at 10:55, Sean Dague  wrote:
> On 09/27/2017 05:15 AM, Marcus Furlong wrote:
>> On 27 September 2017 at 09:23, Michael Still  wrote:
>>>
>>> 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.
>>
>> This is quite a common scenario - staff member who started the
>> instance leaves, and you want to access data on the instance, or
>> maintain/debug the service running on the instance.
>>
>> Hitherto, I have used direct db calls to update the key, so it would
>> be nice if there was an API call to do so.
>
> But you also triggered a rebuild in the process? Or you tweaked the keys
> and did a reboot? This use case came up in the room, but then we started
> trying to figure out if the folks that mostly had it would also need it
> on reboot.

No rebuild, no.

Update the key name and reboot, or, if someone has access, re-run cloud-init.

# rm -fr /var/lib/cloud/instance/sem/
# cloud-init --single -n ssh

Have also thought about just adding the above to a cronjob in the
images to facilitate this scenario (thus avoiding a reboot if noone
has access).

Cheers,
Marcus.

-- 
Marcus Furlong

__
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

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Sean Dague]

On 09/27/2017 05:15 AM, Marcus Furlong wrote:
> On 27 September 2017 at 09:23, Michael Still  wrote:
>>
>> 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.
> 
> This is quite a common scenario - staff member who started the
> instance leaves, and you want to access data on the instance, or
> maintain/debug the service running on the instance.
> 
> Hitherto, I have used direct db calls to update the key, so it would
> be nice if there was an API call to do so.

But you also triggered a rebuild in the process? Or you tweaked the keys
and did a reboot? This use case came up in the room, but then we started
trying to figure out if the folks that mostly had it would also need it
on reboot.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Marcus Furlong]

On 27 September 2017 at 09:23, Michael Still  wrote:
>
> 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.

This is quite a common scenario - staff member who started the
instance leaves, and you want to access data on the instance, or
maintain/debug the service running on the instance.

Hitherto, I have used direct db calls to update the key, so it would
be nice if there was an API call to do so.

Cheers,
Marcus.
-- 
Marcus Furlong

__
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

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Michael Still]

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  wrote:

> On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann 
> 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  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/
>>> ) 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. 

Re: [openstack-dev] [nova] reset key pair during rebuilding

[LIU Yulong]

On Wed, Sep 27, 2017 at 10:29 AM, Matt Riedemann 
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  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 

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Matt Riedemann]

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 
 L498. And there are 
now two proposals.


1. SPEC 1: 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/ 
) 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/ 
 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 

Re: [openstack-dev] [nova] reset key pair during rebuilding

[Zhenyu Zheng]

Hi,

FYI, we are going to use the existing PUT /servers/{server_uuid} API,
adding the 'key_name' field.

On Sat, Sep 23, 2017 at 9:58 PM, 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.opensta
> ck.org/p/nova-ptg-queens L498. And there are now two proposals.
>
> 1. SPEC 1:  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.
>- Easy to use, only one API.
>
> By the way, here is the patch (https://review.openstack.org/#/c/379128/)
> which has implemented this spec. And it stays there more than one year too.
>
> 2. SPEC 2 : 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.
>- 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.
>- 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?
>- 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?
>- 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.
>
>
> 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
>
>
> __
> 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 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-dev] [nova] reset key pair during rebuilding

[LIU Yulong]

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 L498. And there are now two proposals.

1. SPEC 1:  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.
   - Easy to use, only one API.

By the way, here is the patch (https://review.openstack.org/#/c/379128/)
which has implemented this spec. And it stays there more than one year too.

2. SPEC 2 : 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.
   - 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.
   - 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?
   - 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?
   - 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.


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
__
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-dev] [Nova] reset key pair during rebuilding

[LIU Yulong]

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 L498. And there are now
two proposals.

1. SPEC 1:  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.
   - Easy to use, only one API.

By the way, here is the patch (https://review.openstack.org/#/c/379128/)
which has implemented this spec. And it stays there more than one year too.

2. SPEC 2 : 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.
   - 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.
   - 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?
   - 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?
   - 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.


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
__
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