[Yahoo-eng-team] [Bug 2007986] Re: [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full'
Being fixed in Tempest https://review.opendev.org/c/openstack/tempest/+/874704 ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2007986 Title: [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full' Status in neutron: Invalid Status in tempest: In Progress Bug description: Neutron-lib Wallaby CI, job "tempest-full-py3" is failing with error: controller | ERROR: unknown environment 'integrated-full' Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_cf8/874412/1/check/tempest- full-py3/cf87e9c/job-output.txt To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007986/+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 2007915] Re: Can nova-compute connect database directly?
** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/2007915 Title: Can nova-compute connect database directly? Status in OpenStack Identity (keystone): Invalid Bug description: Hello all. Now nova-compute get or update database via rabbitmq message to nova-conductor. If a region has a lot of nova-computes, this will increase the load of rabbitmq and nova-conductor. Can nova-compute connect to database directly? not via rabbitmq and nova-conductor. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/2007915/+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 2008039] [NEW] Can nova-compute connect database directly?
Public bug reported: Hello all. Now nova-compute get or update database via rabbitmq rpc message to nova-conductor. If a region has a lot of nova-computes, this will increase the load of rabbitmq and nova-conductor. Can nova-compute connect to database directly? not via rabbitmq and nova-conductor. Thank you. ** 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/2008039 Title: Can nova-compute connect database directly? Status in OpenStack Compute (nova): New Bug description: Hello all. Now nova-compute get or update database via rabbitmq rpc message to nova-conductor. If a region has a lot of nova-computes, this will increase the load of rabbitmq and nova-conductor. Can nova-compute connect to database directly? not via rabbitmq and nova-conductor. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2008039/+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 2008001] [NEW] [neutron-vpnaas] SQL error during the "vpnservice" creation
Public bug reported: During the VPN service creation, the Neutron API raises an SQL error [1]. That happens when executing: $ openstack vpn service create vpn --router router [1]https://paste.opendev.org/show/bnOLzHQNLRgkhoJMXw0g/ ** Affects: neutron 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/2008001 Title: [neutron-vpnaas] SQL error during the "vpnservice" creation Status in neutron: New Bug description: During the VPN service creation, the Neutron API raises an SQL error [1]. That happens when executing: $ openstack vpn service create vpn --router router [1]https://paste.opendev.org/show/bnOLzHQNLRgkhoJMXw0g/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2008001/+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 2007992] [NEW] [FT] Random failures of ``test_good_address_allocation``
Public bug reported: Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_978/periodic/opendev.org/openstack/neutron/master/neutron- functional/9789c89/testr_results.html Error: https://paste.opendev.org/show/bSzMuP0DqW0yhBAhKBMF/ ** Affects: neutron 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/2007992 Title: [FT] Random failures of ``test_good_address_allocation`` Status in neutron: New Bug description: Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_978/periodic/opendev.org/openstack/neutron/master/neutron- functional/9789c89/testr_results.html Error: https://paste.opendev.org/show/bSzMuP0DqW0yhBAhKBMF/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007992/+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 2007986] Re: [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full'
** Tags added: tempest ** Also affects: tempest 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/2007986 Title: [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full' Status in neutron: New Status in tempest: New Bug description: Neutron-lib Wallaby CI, job "tempest-full-py3" is failing with error: controller | ERROR: unknown environment 'integrated-full' Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_cf8/874412/1/check/tempest- full-py3/cf87e9c/job-output.txt To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007986/+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 2007986] [NEW] [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full'
Public bug reported: Neutron-lib Wallaby CI, job "tempest-full-py3" is failing with error: controller | ERROR: unknown environment 'integrated-full' Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_cf8/874412/1/check/tempest- full-py3/cf87e9c/job-output.txt ** Affects: neutron Importance: Critical Status: New ** Changed in: neutron Importance: Undecided => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2007986 Title: [neutron-lib][stable] Wallaby CI, tempest failing: unknown environment 'integrated-full' Status in neutron: New Bug description: Neutron-lib Wallaby CI, job "tempest-full-py3" is failing with error: controller | ERROR: unknown environment 'integrated-full' Logs: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_cf8/874412/1/check/tempest- full-py3/cf87e9c/job-output.txt To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007986/+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 2007985] [NEW] [ovn-octavia-provider] restore the member provisioning status to NO_MONITOR after delete the HM
Public bug reported: When a HM is creating over a pool, the members associated to it change theis provisioning_status to ONLINE, and if the health checks packets detects an error on communication it will move to ERROR. When the HM is deleted the provisioning status of those members should come back to NO_MONITOR, but now is keeping on the last status (ONLINE or ERROR) ** Affects: neutron Importance: Undecided Assignee: Fernando Royo (froyoredhat) Status: New ** Tags: ovn-octavia-provider ** Changed in: neutron Assignee: (unassigned) => Fernando Royo (froyoredhat) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2007985 Title: [ovn-octavia-provider] restore the member provisioning status to NO_MONITOR after delete the HM Status in neutron: New Bug description: When a HM is creating over a pool, the members associated to it change theis provisioning_status to ONLINE, and if the health checks packets detects an error on communication it will move to ERROR. When the HM is deleted the provisioning status of those members should come back to NO_MONITOR, but now is keeping on the last status (ONLINE or ERROR) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007985/+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 2007982] [NEW] keystone role cache misbehaving in HA setup
Public bug reported: Following up on two mailing list reports [1][2] which seem to have the same root cause. In a HA setup with 3 control nodes (Victoria, baremetal) terraform is used to deploy lots of different k8s clusters (and other stuff). We noticed keystone errors when a project is purged with terraform (cleanly) and a redeployment of the same project (with the same name) is started immediately after that. We did some tests to find out which exact keystone cache it is and it seems to be the role cache (default 600 seconds) which leads to an error in terraform, it reports that the project was not found and refers to the previous ID of the project which is already deleted from the database during the project cleanup. The same deployment works in an identical cloud version except with only one control node, it just works although the cache is enabled as well. I already tried to reduce the cache_time to 30 seconds but that doesn't help (although it takes more than 30 seconds until terraform is ready after the prechecks). I also disabled the role cache entirely which helps with the faster redeployment but the downside of disabling it leads to significantly longer response times when using the dashboard or querying the APIs. Is there any way to tune the role cache in a way so we could have both a reasonable performance as well as being able to redeploy projects without a "sleep 600"? Storage back end is Ceph (Pacific), keystone versions are: control01:~ # rpm -qa | grep keystone python3-keystonemiddleware-9.1.0-lp152.3.20.noarch python3-keystone-18.0.1~dev11-lp152.1.21.noarch python3-keystoneauth1-4.2.1-lp152.3.19.noarch python3-keystoneclient-4.1.0-lp152.5.2.noarch openstack-keystone-18.0.1~dev11-lp152.1.21.noarch [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031122.html [2] https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032258.html ** Affects: keystone Importance: Undecided Status: New ** Project changed: nova => keystone -- 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/2007982 Title: keystone role cache misbehaving in HA setup Status in OpenStack Identity (keystone): New Bug description: Following up on two mailing list reports [1][2] which seem to have the same root cause. In a HA setup with 3 control nodes (Victoria, baremetal) terraform is used to deploy lots of different k8s clusters (and other stuff). We noticed keystone errors when a project is purged with terraform (cleanly) and a redeployment of the same project (with the same name) is started immediately after that. We did some tests to find out which exact keystone cache it is and it seems to be the role cache (default 600 seconds) which leads to an error in terraform, it reports that the project was not found and refers to the previous ID of the project which is already deleted from the database during the project cleanup. The same deployment works in an identical cloud version except with only one control node, it just works although the cache is enabled as well. I already tried to reduce the cache_time to 30 seconds but that doesn't help (although it takes more than 30 seconds until terraform is ready after the prechecks). I also disabled the role cache entirely which helps with the faster redeployment but the downside of disabling it leads to significantly longer response times when using the dashboard or querying the APIs. Is there any way to tune the role cache in a way so we could have both a reasonable performance as well as being able to redeploy projects without a "sleep 600"? Storage back end is Ceph (Pacific), keystone versions are: control01:~ # rpm -qa | grep keystone python3-keystonemiddleware-9.1.0-lp152.3.20.noarch python3-keystone-18.0.1~dev11-lp152.1.21.noarch python3-keystoneauth1-4.2.1-lp152.3.19.noarch python3-keystoneclient-4.1.0-lp152.5.2.noarch openstack-keystone-18.0.1~dev11-lp152.1.21.noarch [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031122.html [2] https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032258.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/2007982/+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 2006734] Re: [OVN] OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number"
Reviewed: https://review.opendev.org/c/openstack/neutron/+/873296 Committed: https://opendev.org/openstack/neutron/commit/fce516e3461054716ff2d4623c240d3e006acbeb Submitter: "Zuul (22348)" Branch:master commit fce516e3461054716ff2d4623c240d3e006acbeb Author: Rodolfo Alonso Hernandez Date: Thu Feb 9 16:36:14 2023 +0100 [OVN] Bump the port revision number in trunk driver When the subport binding information is updated in the OVN trunk driver, the OVN revision number should be updated too, same as in other ``ovn_client`` method, for example. Closes-Bug: #2006734 Change-Id: Icda34910ea7fe308814e0cc60999b465d3540b67 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2006734 Title: [OVN] OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number" Status in neutron: Fix Released Bug description: The OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number" after updating the Neutron DB register. The methods ``OVNTrunkHandler._set_binding_profile`` and ``OVNTrunkHandler._unset_binding_profile`` are called from ``_set_sub_ports`` and ``_unset_sub_ports`` respectively. These methods create a Neutron DB and a OVN DB transactions in the same with clause. Inside both transactions, the port register (Neutron DB and OVN DB) is modified. However, the OVN register revision_number is not bumped consequently. That forces the maintenance task to review the OVN register and force an update. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2006734/+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 2007968] [NEW] Flavors may not meet the image minimum requirement when resize
Public bug reported: Description === When resize instance, the flavors returned may not meet the image minimum memory requirement, resizing instance ignores the minimum memory limit of the image, which may cause the resizing be successfully, but the instance fails to start because the memory is too small to run the system. Steps to reproduce == 1.create an instance with image min_ram 4096 2.resize the instance 3.watch the returned flavors Expected result === do not include the flavors which memory less than 4096. Actual result = returned all of the visible flavors. Environment === Logs & Configs == ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/2007968 Title: Flavors may not meet the image minimum requirement when resize Status in OpenStack Dashboard (Horizon): New Bug description: Description === When resize instance, the flavors returned may not meet the image minimum memory requirement, resizing instance ignores the minimum memory limit of the image, which may cause the resizing be successfully, but the instance fails to start because the memory is too small to run the system. Steps to reproduce == 1.create an instance with image min_ram 4096 2.resize the instance 3.watch the returned flavors Expected result === do not include the flavors which memory less than 4096. Actual result = returned all of the visible flavors. Environment === Logs & Configs == To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2007968/+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 2007959] [NEW] Package "python-devel [platform:rpm test]" defined by bindep fails on RHEL 8
Public bug reported: Description === On "stable/train" at "bindep.txt", line "python-devel [platform:rpm test]" should be "python3-devel [platform:rpm test]", otherwise during CI automation tools will fail while trying to install the package on RHEL 8. Versions after train have performed this change, so I expect this is not the first time the problem has happened. Steps to reproduce == 1.- On stock RHEL 8.4, run: dnf install python-devel 2.- RHEL will complain that the package is unknown. Expected result === RHEL is capable of installing the "python36-devel" package and its dependencies through the "python3-devel" alias. Actual result = RHEL does not find the "python-devel" package. Environment === RHEL 8.4 Python 3.6 ** Affects: nova Importance: Undecided Assignee: Jorge San Emeterio (jsanemet) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Jorge San Emeterio (jsanemet) ** Changed in: nova Status: New => In Progress -- 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/2007959 Title: Package "python-devel [platform:rpm test]" defined by bindep fails on RHEL 8 Status in OpenStack Compute (nova): In Progress Bug description: Description === On "stable/train" at "bindep.txt", line "python-devel [platform:rpm test]" should be "python3-devel [platform:rpm test]", otherwise during CI automation tools will fail while trying to install the package on RHEL 8. Versions after train have performed this change, so I expect this is not the first time the problem has happened. Steps to reproduce == 1.- On stock RHEL 8.4, run: dnf install python-devel 2.- RHEL will complain that the package is unknown. Expected result === RHEL is capable of installing the "python36-devel" package and its dependencies through the "python3-devel" alias. Actual result = RHEL does not find the "python-devel" package. Environment === RHEL 8.4 Python 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2007959/+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 2007938] [NEW] [DHCP] Metadata IPv6 duplicated address when setting the interface
Public bug reported: When setting the IPv6 address for the metadata interface [2], it could happen that the IPv6 address can be considered as duplicated [2]. I can't provide a way to replicate this issue as it is happening randomly. The IPv6 address in the DHCP namespace is set as "dadfailed tentative". [2]https://github.com/openstack/neutron/blob/8455edda46b4a465e2f184b59ad31476ce79c6c4/neutron/agent/metadata/driver.py#L244-L246 [1]https://paste.opendev.org/show/bXDAHSHpvEAIHwdPjxrB/ ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2007938 Title: [DHCP] Metadata IPv6 duplicated address when setting the interface Status in neutron: New Bug description: When setting the IPv6 address for the metadata interface [2], it could happen that the IPv6 address can be considered as duplicated [2]. I can't provide a way to replicate this issue as it is happening randomly. The IPv6 address in the DHCP namespace is set as "dadfailed tentative". [2]https://github.com/openstack/neutron/blob/8455edda46b4a465e2f184b59ad31476ce79c6c4/neutron/agent/metadata/driver.py#L244-L246 [1]https://paste.opendev.org/show/bXDAHSHpvEAIHwdPjxrB/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2007938/+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 2007922] [NEW] Cleanup pending instances in "building" state
Public bug reported: Following up on the ML thread [1], it was recommended to create a bug report. After a network issue in a Victoria cluster (3 control nodes in HA mode, 26 compute nodes) some instance builds were interrupted. Some of them could be cleaned up with 'openstack server delete' but two of them can not. They already have a mapping but can not be removed (or "reset-state") by nova. Those are both amphora instances from octavia: control01:~ # openstack server list --project service -c ID -c Name -c Status -f value | grep BUILD 0453a7e5-e4f9-419b-ad71-d837a20ef6bb amphora-0ee32901-0c59-4752-8253-35b66da176ea BUILD dc8cdc3a-f6b2-469b-af6f-ba2aa130ea9b amphora-4990a47b-fe8a-431a-90ec-5ac2368a5251 BUILD control01:~ # openstack server delete amphora-0ee32901-0c59-4752-8253-35b66da176ea No server with a name or ID of 'amphora-0ee32901-0c59-4752-8253-35b66da176ea' exists. control01:~ # openstack server show 0453a7e5-e4f9-419b-ad71-d837a20ef6bb ERROR (CommandError): No server with a name or ID of '0453a7e5-e4f9-419b-ad71-d837a20ef6bb' exists. The database tables referring to the UUID 0453a7e5-e4f9-419b-ad71-d837a20ef6bb are these: nova_cell0/instance_id_mappings.ibd nova_cell0/instance_info_caches.ibd nova_cell0/instance_extra.ibd nova_cell0/instances.ibd nova_cell0/instance_system_metadata.ibd octavia/amphora.ibd nova_api/instance_mappings.ibd nova_api/request_specs.ibd I can provide both debug logs and database queries, just let me know what exactly is required. The storage back end is ceph (Pacific), we use neutron with OpenVSwitch, the exact nova versions are: control01:~ # rpm -qa | grep nova openstack-nova-conductor-22.2.2~dev15-lp152.1.25.noarch openstack-nova-api-22.2.2~dev15-lp152.1.25.noarch openstack-nova-novncproxy-22.2.2~dev15-lp152.1.25.noarch python3-novaclient-17.2.0-lp152.3.2.noarch openstack-nova-scheduler-22.2.2~dev15-lp152.1.25.noarch openstack-nova-22.2.2~dev15-lp152.1.25.noarch python3-nova-22.2.2~dev15-lp152.1.25.noarch [1] https://lists.openstack.org/pipermail/openstack- discuss/2023-February/032308.html ** Affects: nova Importance: Undecided Status: New ** Description changed: Following up on the ML thread [1], it was recommended to create a bug report. After a network issue in a Victoria cluster (3 control nodes in HA mode, 26 compute nodes) some instance builds were interrupted. Some of them could be cleaned up with 'openstack server delete' but two of them can not. They already have a mapping but can not be removed (or "reset-state") by nova. Those are both amphora instances from octavia: control01:~ # openstack server list --project service -c ID -c Name -c Status -f value | grep BUILD 0453a7e5-e4f9-419b-ad71-d837a20ef6bb amphora-0ee32901-0c59-4752-8253-35b66da176ea BUILD dc8cdc3a-f6b2-469b-af6f-ba2aa130ea9b amphora-4990a47b-fe8a-431a-90ec-5ac2368a5251 BUILD control01:~ # openstack server delete amphora-0ee32901-0c59-4752-8253-35b66da176ea - No server with a name or ID of + No server with a name or ID of 'amphora-0ee32901-0c59-4752-8253-35b66da176ea' exists. control01:~ # openstack server show 0453a7e5-e4f9-419b-ad71-d837a20ef6bb - ERROR (CommandError): No server with a name or ID of + ERROR (CommandError): No server with a name or ID of '0453a7e5-e4f9-419b-ad71-d837a20ef6bb' exists. - The database tables referring to the UUID + The database tables referring to the UUID 0453a7e5-e4f9-419b-ad71-d837a20ef6bb are these: nova_cell0/instance_id_mappings.ibd nova_cell0/instance_info_caches.ibd nova_cell0/instance_extra.ibd nova_cell0/instances.ibd nova_cell0/instance_system_metadata.ibd octavia/amphora.ibd nova_api/instance_mappings.ibd nova_api/request_specs.ibd I can provide both debug logs and database queries, just let me know what exactly is required. + The storage back end is ceph (Pacific), we use neutron with OpenVSwitch, + the exact nova versions are: + + control01:~ # rpm -qa | grep nova + openstack-nova-conductor-22.2.2~dev15-lp152.1.25.noarch + openstack-nova-api-22.2.2~dev15-lp152.1.25.noarch + openstack-nova-novncproxy-22.2.2~dev15-lp152.1.25.noarch + python3-novaclient-17.2.0-lp152.3.2.noarch + openstack-nova-scheduler-22.2.2~dev15-lp152.1.25.noarch + openstack-nova-22.2.2~dev15-lp152.1.25.noarch + python3-nova-22.2.2~dev15-lp152.1.25.noarch + [1] https://lists.openstack.org/pipermail/openstack- discuss/2023-February/032308.html -- 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/2007922 Title: Cleanup pending instances in "building" state Status in OpenStack Compute (nova): New Bug description: Following up on the ML thread [1], it was recommended to create a bug report. After a network issue in a Victoria cluster (3 control nodes in HA mode, 26 compute nodes) some instance builds were interrupted. Some of them could
[Yahoo-eng-team] [Bug 2007924] [NEW] stevedore always shows error if boto3 is not installed
Public bug reported: Currently stevedore always dump the following error in case boto3 is not installed in the system. ERROR stevedore.extension [-] Could not load 'glance.store.s3.Store': No module named 'boto3': ModuleNotFoundError: No module named 'boto3' ERROR stevedore.extension [-] Could not load 's3': No module named 'boto3': ModuleNotFoundError: No module named 'boto3' This error is red herring because missing boto3 does not harm unless s3 backend is actually used. The other stores such as swift store ignores missing library during loading drivers but fails in case swift store is actually requested. It'd be helpful to follow that strategy for s3 backend to avoid confusing error. ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: New ** Changed in: glance Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/2007924 Title: stevedore always shows error if boto3 is not installed Status in Glance: New Bug description: Currently stevedore always dump the following error in case boto3 is not installed in the system. ERROR stevedore.extension [-] Could not load 'glance.store.s3.Store': No module named 'boto3': ModuleNotFoundError: No module named 'boto3' ERROR stevedore.extension [-] Could not load 's3': No module named 'boto3': ModuleNotFoundError: No module named 'boto3' This error is red herring because missing boto3 does not harm unless s3 backend is actually used. The other stores such as swift store ignores missing library during loading drivers but fails in case swift store is actually requested. It'd be helpful to follow that strategy for s3 backend to avoid confusing error. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/2007924/+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
