[Bug 1843708] Re: [SRU] Key-pair is not updated during the rebuild
Hua Zhang
1843708 at bugs.launchpad.net
Tue May 23 09:24:04 UTC 2023
Hi Ćukasz, after rebuilding a VM with different keypairs on bionic, we
can use the old keypair for ssh login, but we cannot use the new
keypair. This is not 'expected behaviour' for nova rebuild. bionic uses
17.0.13, which has this issue.
--
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
More information about the Ubuntu-sponsors
mailing list