[Yahoo-eng-team] [Bug 1997216] [NEW] virt/libvirt/host.py: _test_connection is not reliable with modularized libvirtd services
Public bug reported: Description === the virt/libvirt/host.py _test_connection function of openstack nova service is not reliable with modularized libvirtd services and cannot reestablish connection if some module of libvirt is restarted. The modularized libvirt uses multiple daemons Like ... virtnodedevd virtnetworkd virtsecretd ... in case one of them is restarted the nova-compute still thinks the connection is working. However using particular module will fail when used later. In the nova-compute service log we can see: internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed Steps to reproduce == 1/ use openstack with modularized libvirtd as on CentOS Stream 9 2/ gracefully restart virtnodedevd.service $ systemctl restart virtnodedevd.service 3/ check logs of openstack about connection issue (repeating one each 30s) "internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed" Expected result === "_test_connection" function figures out the needed libvirt's module socket was closed and it will try to "open new connection". Actual result = Openstack Nova service is not able to use libvirt's service module if the module is restarted. Environment === CentOS Stream 9, Openstack Yoga ** 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/1997216 Title: virt/libvirt/host.py: _test_connection is not reliable with modularized libvirtd services Status in OpenStack Compute (nova): New Bug description: Description === the virt/libvirt/host.py _test_connection function of openstack nova service is not reliable with modularized libvirtd services and cannot reestablish connection if some module of libvirt is restarted. The modularized libvirt uses multiple daemons Like ... virtnodedevd virtnetworkd virtsecretd ... in case one of them is restarted the nova-compute still thinks the connection is working. However using particular module will fail when used later. In the nova-compute service log we can see: internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed Steps to reproduce == 1/ use openstack with modularized libvirtd as on CentOS Stream 9 2/ gracefully restart virtnodedevd.service $ systemctl restart virtnodedevd.service 3/ check logs of openstack about connection issue (repeating one each 30s) "internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed" Expected result === "_test_connection" function figures out the needed libvirt's module socket was closed and it will try to "open new connection". Actual result = Openstack Nova service is not able to use libvirt's service module if the module is restarted. Environment === CentOS Stream 9, Openstack Yoga To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1997216/+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 1972819] [NEW] Firecracker Metadata Service + NoCloud source - API TOKEN required with MMDS v2 (v1 deprecated)
Public bug reported: Hello, I noticed the Firecracker 1.1.0 hypervisor announced MMDS v1 deprecation in favor of MMDS v2 (https://github.com/firecracker- microvm/firecracker/releases/tag/v1.1.0). The MMDS v2 is a a session-oriented and request to get and use API_TOKEN like EC2 Metadata service IMDSv2. Cloud-init can be used with firecracker medatada service using NoCloud data source as is described in https://ongres.com/blog/automation-to- run-vms-based-on-vanilla-cloud-images-on-firecracker/. However this is going to stop to work with MMDS v2 where the guest cannot get any user- data/meta-data by cloud-init any more due to missing API_TOKEN in request. Can you please implement API_TOKEN feature into NoCloud data source? Many thanks, ** Affects: cloud-init Importance: Undecided Status: New -- 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/1972819 Title: Firecracker Metadata Service + NoCloud source - API TOKEN required with MMDS v2 (v1 deprecated) Status in cloud-init: New Bug description: Hello, I noticed the Firecracker 1.1.0 hypervisor announced MMDS v1 deprecation in favor of MMDS v2 (https://github.com/firecracker- microvm/firecracker/releases/tag/v1.1.0). The MMDS v2 is a a session-oriented and request to get and use API_TOKEN like EC2 Metadata service IMDSv2. Cloud-init can be used with firecracker medatada service using NoCloud data source as is described in https://ongres.com/blog/automation-to- run-vms-based-on-vanilla-cloud-images-on-firecracker/. However this is going to stop to work with MMDS v2 where the guest cannot get any user-data/meta-data by cloud-init any more due to missing API_TOKEN in request. Can you please implement API_TOKEN feature into NoCloud data source? Many thanks, To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1972819/+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
