[Yahoo-eng-team] [Bug 1894771] [NEW] Hypervisor shows negative numbers after launching instances on baremetal nodes
Public bug reported:
Testing with Train version with ironic driver.
Before launching instances on baremetal nodes, # nova hypervisor-show
command shows 0 for vcpus, memory and disk fields, which are set to zero in
ironic.driver code.
This is still acceptable as baremetal resources are counted in resource class,
however, after launching instance on the baremetal node, the vcpu/mem/disk
fields appear to be negative in hypervisor-show details, and the negative
numbers correlate with the flavor's vcpu/mem/disk fields.
[root@train ~(keystone_admin)]# nova hypervisor-show
e12c91fb-4c73-406f-8b9e-b0ef3c9c829a
+-+--+
| Property| Value|
+-+--+
| cpu_info| {} |
| current_workload| 0|
| disk_available_least| 0|
| free_disk_gb| -100 |
| free_ram_mb | -16384 |
| host_ip | 192.168.10.111 |
| hypervisor_hostname | e12c91fb-4c73-406f-8b9e-b0ef3c9c829a |
| hypervisor_type | ironic |
| hypervisor_version | 1|
| id | e12c91fb-4c73-406f-8b9e-b0ef3c9c829a |
| local_gb| 0|
| local_gb_used | 100 |
| memory_mb | 0|
| memory_mb_used | 16384|
| running_vms | 1|
| service_disabled_reason | None |
| service_host| train.ironic|
| service_id | 23464515-e938-47b1-807e-fb0e3d8250e3 |
| state | up |
| status | enabled |
| vcpus | 0|
| vcpus_used | 8|
+-+--+
The hypervisor detail does not affect the functions of baremetal instances, but
is quite confusing.
Besides, nova quotas and usages are also affected by the baremetal flavor's
vcpu/mem/disk fields, which maybe not able to describe the resources that the
instance occupies.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1894771
Title:
Hypervisor shows negative numbers after launching instances on
baremetal nodes
Status in OpenStack Compute (nova):
New
Bug description:
Testing with Train version with ironic driver.
Before launching instances on baremetal nodes, # nova hypervisor-show
command shows 0 for vcpus, memory and disk fields, which are set to zero in
ironic.driver code.
This is still acceptable as baremetal resources are counted in resource
class, however, after launching instance on the baremetal node, the
vcpu/mem/disk fields appear to be negative in hypervisor-show details, and the
negative numbers correlate with the flavor's vcpu/mem/disk fields.
[root@train ~(keystone_admin)]# nova hypervisor-show
e12c91fb-4c73-406f-8b9e-b0ef3c9c829a
+-+--+
| Property| Value|
+-+--+
| cpu_info| {} |
| current_workload| 0|
| disk_available_least| 0|
| free_disk_gb| -100 |
| free_ram_mb | -16384 |
| host_ip | 192.168.10.111 |
| hypervisor_hostname | e12c91fb-4c73-406f-8b9e-b0ef3c9c829a |
| hypervisor_type | ironic |
| hypervisor_version | 1|
| id | e12c91fb-4c73-406f-8b9e-b0ef3c9c829a |
| local_gb| 0|
| local_gb_used | 100 |
| memory_mb | 0|
| memory_mb_used | 16384|
| running_vms | 1|
| service_disabled_reason | None |
| service_host| train.ironic
[Yahoo-eng-team] [Bug 1531880] Re: Failed to start Initial cloud-init job (pre-networking)
Hey folks, I believe that this has been fixed in cloud-init 20.3 (specifically this commit: https://github.com/canonical/cloud- init/commit/0755cff078d5931e1d8e151bdcb84afb92bc0f02) so I'm going to move this to Fix Released. If you are seeing this error on an earlier version of cloud-init, it generally indicates that cloud-init failed on a _previous_ boot (because before that fix, a failed boot meant it would incorrectly create a directory where a symlink should have been, leading to the `IsADirectoryError` when the old not-actually-a-symlink is `rm`d on subsequent boots). If you can identify the cause of this earlier failure, please feel free to file a bug for it! Thanks, Dan ** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1531880 Title: Failed to start Initial cloud-init job (pre-networking) Status in cloud-init: Fix Released Bug description: Linux Ubuntu-Gnome-Server 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 Cloud-init 0.7.7 systemctl -l status cloud-init-local ● cloud-init-local.service - Initial cloud-init job (pre-networking) Loaded: loaded (/lib/systemd/system/cloud-init-local.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2016-01-07 15:34:33 CET; 6min ago Process: 961 ExecStart=/usr/bin/cloud-init init --local (code=exited, status=1/FAILURE) Main PID: 961 (code=exited, status=1/FAILURE) Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1547, in del_file Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: raise e Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1544, in del_file Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: os.unlink(path) Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: IsADirectoryError: [Errno 21] Is a directory: '/var/lib/cloud/instance' Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Main process exited, code=exited, status=1/FAILURE Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: Failed to start Initial cloud-init job (pre-networking). Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Unit entered failed state. Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1531880/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1891673] Re: qrouter ns ip rules not deleted when fip removed from vm
** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/train Importance: Undecided Status: New ** Also affects: cloud-archive/victoria Importance: Undecided Status: New ** Also affects: cloud-archive/ussuri Importance: Undecided Status: New ** Also affects: cloud-archive/rocky Importance: Undecided Status: New ** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Also affects: cloud-archive/stein Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1891673 Title: qrouter ns ip rules not deleted when fip removed from vm Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive queens series: New Status in Ubuntu Cloud Archive rocky series: New Status in Ubuntu Cloud Archive stein series: New Status in Ubuntu Cloud Archive train series: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in neutron: In Progress Bug description: With Bionic Stein using dvr_snat if I add a floating ip to a vm then remove the floating ip, the corresponding ip rules in the associated qrouter ns local to the instance are not deleted which results in no longer being able to reach the external network because packets are still sent to the fip namespace (via rfp-/fpr-) e.g. in my compute host running a vm whose address is 192.168.21.28 for which i have removed the fip I still see: # ip netns exec qrouter-5e45608f-33d4-41bf-b3ba-915adf612e65 ip rule list 0: from all lookup local 32765: from 192.168.21.28 lookup 16 32766: from all lookup main 32767: from all lookup default 3232240897: from 192.168.21.1/24 lookup 3232240897 3232241231: from 192.168.22.79/24 lookup 3232241231 And table 16 leads to: # ip netns exec qrouter-5e45608f-33d4-41bf-b3ba-915adf612e65 ip route show table 16 default via 169.254.109.249 dev rfp-5e45608f-3 Which results in the instance no longer being able to reach the external network (packets are never sent to the snat- ns in my case). The workaround is to delete that ip rule but neutron should be taking care of this. Looks like the culprit is in neutron/agent/l3/dvr_local_router.py:floating_ip_removed_dist Note that the NAT rules were successfully removed from iptables so looks like it is just this bit that is left behind. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1891673/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1890803] Re: Groovy amd64 / arm64 / PowerPC deployment seems not working
Groovy deployment on ppc64el hardware now working. Marking "ubuntu- power-systems" series as "Fix Released". Thanks! ** Changed in: ubuntu-power-systems Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1890803 Title: Groovy amd64 / arm64 / PowerPC deployment seems not working Status in cloud-init: Invalid Status in cloud-initramfs-tools: Fix Committed Status in MAAS: Triaged Status in ubuntu-kernel-tests: Triaged Status in The Ubuntu-power-systems project: Fix Released Status in cloud-initramfs-tools package in Ubuntu: Fix Released Bug description: All bare-metal deployment tasks have failed on our bare-metal maas server and the PowerMAAS / HyperMAAS (image synced on maas server). Deployment failed with: Installation was aborted. Need to further investigate this. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1890803/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1894621] [NEW] live migration force node not working with v2.67
Public bug reported: Since "Stein", by default, is not possible to "force" live-migrate an instance to a node without schedule verification. This means that if the target node is disable the live-migration will fail. This was introduced with: https://github.com/openstack/nova/commit/36a91936a821b0c1f502d7d8f1ffd8c4d179d212 https://review.opendev.org/#/c/634600/ This change takes effect starting in microversion v2.68. We can force the client to use v2.67. Using "--os-compute-api-version 2.67" but it's not working ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1894621 Title: live migration force node not working with v2.67 Status in OpenStack Compute (nova): New Bug description: Since "Stein", by default, is not possible to "force" live-migrate an instance to a node without schedule verification. This means that if the target node is disable the live-migration will fail. This was introduced with: https://github.com/openstack/nova/commit/36a91936a821b0c1f502d7d8f1ffd8c4d179d212 https://review.opendev.org/#/c/634600/ This change takes effect starting in microversion v2.68. We can force the client to use v2.67. Using "--os-compute-api-version 2.67" but it's not working To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1894621/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
