[Bug 1843708] Re: [SRU] Key-pair is not updated during the rebuild

Mon May 22 04:26:21 UTC 2023

hi @vorlon, I have updated the bug description to remove the part "see
the original bug description below", thanks

** Description changed:

- [ Impact ]
+ [Impact]

-  * See the original bug description below
+ During rebuilds, the customer was unable to update the instance's
+ keypair.

- [ Test Plan ]
+ [Test Case]

-  * See the original bug description below
+ - create a bionic openstack test env

- [ Where problems could occur ]
+ - choose the key 'testkey' to create an instance

-  This fix 6a7a78a44 is already in stable/queens and all versions since
+ openstack keypair create mykey --public-key ~/.ssh/id_rsa.pub 
+ openstack keypair create testkey --public-key /home/ubuntu/testkey.pub
+ openstack server create --flavor m1.small --image jammy --key-name testkey --network=$(openstack network show private -f value -c id)  i1
+ 
+ - create a new instance from the snapshot and choose a different keypair
+ 'mykey' at rebuild time
+ 
+ openstack --os-compute-api-version 2.54 server rebuild --image jammy --key-name mykey --name i1 i1
+ sudo ip netns exec qrouter-xxx ssh ubuntu at 192.168.21.4 -i ~/testkey.priv -v
+ sudo ip netns exec qrouter-xxx ssh ubuntu at 192.168.21.4 -i ~/id_rsa -v
+ 
+ the new instance should accept the new key and reject the old key, but
+ the result is the new instance rejects the new key but old key still
+ works.
+ 
+ [Regression Potential]
+ 
+ This fix 6a7a78a44 is already in stable/queens and all versions since
  queens, bionic uses 17.0.13 rather than stable/queens, we just SRU this
  fix to 17.0.13 so there can't be any regression theoretically. On the
  other hand, code change is limited to _save_keypairs according to
  https://review.opendev.org/c/openstack/nova/+/683043/19/nova/objects/instance.py
- so the regressions is also limited _save_keypairs . The test will also
- ensure that other logic beyond _save_keypairs. so I think it's safe.
+ so the regressions is also limited in _save_keypairs . The test will
+ also ensure that other logic beyond _save_keypairs. I have tested this
+ fix, it works. so I think it's safe.

- [ Other Info ]
+ [Others]

-  * the fix 6a7a78a44 is already in stable/queens, but not in 17.0.13
- 
- Original Bug Description
+ Original Bug Description Below
  ===========

  When we want to rebuild an instance and change the keypair we can specified it with :
- openstack --os-compute-api-version 2.54  server rebuild --image "Debian 10" --key-name key1 instance1
+ openstack --os-compute-api-version 2.54 server rebuild --image "Debian 10" --key-name key1 instance1

  This comes from this implementation :
  https://review.opendev.org/#/c/379128/
  https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/rebuild-keypair-reset.html

  But when rebuilding the instance, Cloud-Init will set the key in authorized_keys from
  http://169.254.169.254/openstack/latest/meta_data.json

  And this meta_data.json uses the keys from instance_extra tables
  But the keypair will be updated in the 'instances' table but not in the 'instance_extra' table.

  So the keypair is not updated inside the VM

  May be this is the function for saving the keypair, but the save() do nothing :
  https://opendev.org/openstack/nova/src/branch/master/nova/objects/instance.py#L714

  Steps to reproduce
  ==================

  - Deploy a DevStack
  - Boot an instance with keypair key1
  - Rebuild it with key2
  - A nova show will show the key_name key2, keypairs object in table instance_extra is not updated and you cannot connect with key2 to the instance

  Expected result
  ===============
  Connecte to the Vm with the new keypair added during the rebuild call

  Actual result
  =============
  The keypair added during the rebuild call is not set in the VM

  Environment
  ===========
  I tested it on a Devstack from master and we have the behaviour.
  NOVA : commit 5fa49cd0b8b6015aa61b4312b2ce1ae780c42c64

** Changed in: nova (Ubuntu Bionic)
       Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1843708

Title:
  [SRU] Key-pair is not updated during the rebuild

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive rocky series:
  Won't Fix
Status in Ubuntu Cloud Archive stein series:
  Fix Released
Status in Ubuntu Cloud Archive train series:
  Fix Released
Status in Ubuntu Cloud Archive ussuri series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Fix Released
Status in OpenStack Compute (nova) rocky series:
  Fix Released
Status in OpenStack Compute (nova) stein series:
  Fix Released
Status in OpenStack Compute (nova) train series:
  Fix Released
Status in OpenStack Compute (nova) ussuri series:
  Fix Released
Status in nova package in Ubuntu:
  Invalid
Status in nova source package in Bionic:
  New
Status in nova source package in Focal:
  Fix Released

Bug description:
  [Impact]

  During rebuilds, the customer was unable to update the instance's
  keypair.

  [Test Case]

  - create a bionic openstack test env

  - choose the key 'testkey' to create an instance

  openstack keypair create mykey --public-key ~/.ssh/id_rsa.pub 
  openstack keypair create testkey --public-key /home/ubuntu/testkey.pub
  openstack server create --flavor m1.small --image jammy --key-name testkey --network=$(openstack network show private -f value -c id)  i1

  - create a new instance from the snapshot and choose a different
  keypair 'mykey' at rebuild time

  openstack --os-compute-api-version 2.54 server rebuild --image jammy --key-name mykey --name i1 i1
  sudo ip netns exec qrouter-xxx ssh ubuntu at 192.168.21.4 -i ~/testkey.priv -v
  sudo ip netns exec qrouter-xxx ssh ubuntu at 192.168.21.4 -i ~/id_rsa -v

  the new instance should accept the new key and reject the old key, but
  the result is the new instance rejects the new key but old key still
  works.

  [Regression Potential]

  This fix 6a7a78a44 is already in stable/queens and all versions since
  queens, bionic uses 17.0.13 rather than stable/queens, we just SRU
  this fix to 17.0.13 so there can't be any regression theoretically. On
  the other hand, code change is limited to _save_keypairs according to
  https://review.opendev.org/c/openstack/nova/+/683043/19/nova/objects/instance.py
  so the regressions is also limited in _save_keypairs . The test will
  also ensure that other logic beyond _save_keypairs. I have tested this
  fix, it works. so I think it's safe.

  [Others]

  Original Bug Description Below
  ===========

  When we want to rebuild an instance and change the keypair we can specified it with :
  openstack --os-compute-api-version 2.54 server rebuild --image "Debian 10" --key-name key1 instance1

  This comes from this implementation :
  https://review.opendev.org/#/c/379128/
  https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/rebuild-keypair-reset.html

  But when rebuilding the instance, Cloud-Init will set the key in authorized_keys from
  http://169.254.169.254/openstack/latest/meta_data.json

  And this meta_data.json uses the keys from instance_extra tables
  But the keypair will be updated in the 'instances' table but not in the 'instance_extra' table.

  So the keypair is not updated inside the VM

  May be this is the function for saving the keypair, but the save() do nothing :
  https://opendev.org/openstack/nova/src/branch/master/nova/objects/instance.py#L714

  Steps to reproduce
  ==================

  - Deploy a DevStack
  - Boot an instance with keypair key1
  - Rebuild it with key2
  - A nova show will show the key_name key2, keypairs object in table instance_extra is not updated and you cannot connect with key2 to the instance

  Expected result
  ===============
  Connecte to the Vm with the new keypair added during the rebuild call

  Actual result
  =============
  The keypair added during the rebuild call is not set in the VM

  Environment
  ===========
  I tested it on a Devstack from master and we have the behaviour.
  NOVA : commit 5fa49cd0b8b6015aa61b4312b2ce1ae780c42c64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1843708/+subscriptions