[Yahoo-eng-team] [Bug 2078999] Re: nova_manage: Image property restored after migration
Reviewed: https://review.opendev.org/c/openstack/nova/+/924319 Committed: https://opendev.org/openstack/nova/commit/2a1fad41453ca7ce15b1cd9b517055c4ccdd12cf Submitter: "Zuul (22348)" Branch:master commit 2a1fad41453ca7ce15b1cd9b517055c4ccdd12cf Author: zhong.zhou Date: Wed Jul 17 18:29:46 2024 +0800 nova-manage: modify image properties in request_spec At present, we can modify the properties in the instance system_metadata through the sub command image_property of nova-manage, but there may be inconsistencies between their values and those in request_specs. And the migration is based on request_specs, so the same image properties are also written to request_specs. Closes-Bug: 2078999 Change-Id: Id36ecd022cb6f7f9a0fb131b0d202b79715870a9 ** Changed in: nova Status: In Progress => Fix Released -- 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/2078999 Title: nova_manage: Image property restored after migration Status in OpenStack Compute (nova): Fix Released Bug description: Description === I use "nova-manage image_property" to modify image meta of an instance, however, the change lost and restored to the older prop after migration. Steps to reproduce == 1.create an instance and set a property in image like hw_qemu_guest_agent=False 2.use nova-manage image_property set to modify the instance and the prop expected to True 3.migration the instance Expected result === hw_qemu_guest_agent is always True after migration Actual result = hw_qemu_guest_agent was restored to False after migration To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2078999/+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 2081290] [NEW] nova still check the image data-file even disable_deep_image_inspection is set True
Public bug reported: Base on the security leak bug 2059809, when i set 'disable_deep_image_inspection = True' to skip the image data-file check in nova-compute.conf file [workarounds] group, create vm fails with the exception: 'nova.exception.BuildAbortException: Build of instance 30c2ae32-bc04-4253-9b54-b4f55c4997f0 aborted: Image a711872c-b8b9-417f-a7a4-3f6723194f33 is unacceptable: fmt=qcow2 has data-file: /etc/passwd', seems the data-file in images still be checked. ** 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/2081290 Title: nova still check the image data-file even disable_deep_image_inspection is set True Status in OpenStack Compute (nova): New Bug description: Base on the security leak bug 2059809, when i set 'disable_deep_image_inspection = True' to skip the image data-file check in nova-compute.conf file [workarounds] group, create vm fails with the exception: 'nova.exception.BuildAbortException: Build of instance 30c2ae32-bc04-4253-9b54-b4f55c4997f0 aborted: Image a711872c-b8b9-417f-a7a4-3f6723194f33 is unacceptable: fmt=qcow2 has data-file: /etc/passwd', seems the data-file in images still be checked. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2081290/+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 2081252] [NEW] [designate] 2023.2 n-t-p job failing, test "test_port_with_publishing_subnet"
You have been subscribed to a public bug: The CI job "neutron-tempest-plugin-designate-scenario-2023-2" is frequently failing [1]. The failing test is "test_port_with_publishing_subnet". Logs: * https://108db2f44ab966c3afef-3578f4b3c7df6e8f4dbcf87a4a72da28.ssl.cf2.rackcdn.com/929592/3/check/neutron-tempest-plugin-designate-scenario-2023-2/0ee146d/testr_results.html * https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_907/929592/3/check/neutron-tempest-plugin-designate-scenario-2023-2/9077de5/testr_results.html Snippet: https://paste.opendev.org/show/bAwChjRpjViOkugxgydZ/ [1]https://zuul.opendev.org/t/openstack/builds?job_name=neutron-tempest- plugin-designate-scenario-2023-2&skip=0 ** Affects: neutron Importance: Critical Status: New -- [designate] 2023.2 n-t-p job failing, test "test_port_with_publishing_subnet" https://bugs.launchpad.net/bugs/2081252 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 2081109] Re: security-groups-rules-belongs-to-default-sg extension is not documented in api-ref
Hello Ihar: The default "security group default rules" is a different API. This API [1][2] allows to create a set of rule templates for the default SG. In other words: we can define what rules will be automatically added to a project default SG, instead of the hardcoded ones. The flag "security_group_rule.belongs_to_default_sg" is a new field added to the SG rules resource. It is documented in [3] (implemented in [4]). Regards. [1]https://specs.openstack.org/openstack/neutron-specs/specs/2023.2/configurable-default-sg-rules.html [2]https://review.opendev.org/q/topic:%22bug/1983053%22 [3]https://docs.openstack.org/api-ref/network/v2/#security-group-rules [4]https://review.opendev.org/c/openstack/neutron-lib/+/883939 ** 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/2081109 Title: security-groups-rules-belongs-to-default-sg extension is not documented in api-ref Status in neutron: Invalid Bug description: It was merged in https://review.opendev.org/c/openstack/neutron/+/883907 but I don't see the new field mentioned in https://docs.openstack.org/api- ref/network/v2/#security-group-default-rules-security-group-default- rules To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2081109/+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 1998268] Re: Fernet uid/gid logic issue
Reviewed: https://review.opendev.org/c/openstack/keystone/+/866096 Committed: https://opendev.org/openstack/keystone/commit/1cf7d94d6eb27aff92d3a612ee05efcc19e08917 Submitter: "Zuul (22348)" Branch:master commit 1cf7d94d6eb27aff92d3a612ee05efcc19e08917 Author: Sam Morrison Date: Wed Nov 30 12:16:40 2022 +1100 Fix logic of fernet creation when running as root Running `keystone-manage fernet_rotate --keystone-user root --keystone-group keystone` Will cause group to be root not keystone due to checking the uid (0) against false, as opposed to None. Closes-Bug: #1998268 Change-Id: Ib20550bf698f4fab381b48571ff8d096a2ae3335 ** Changed in: keystone Status: In Progress => Fix Released -- 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/1998268 Title: Fernet uid/gid logic issue Status in OpenStack Identity (keystone): Fix Released Bug description: Running keystone-manage fernet_rotate --keystone-user root --keystone-group keystone Will not work as expected due to some wrong logic when uid is set to 0 due to 0 == False The new 0 key will have ownership of root:root, not root:keystone To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1998268/+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 2081161] Re: KeyError: 'ip_version' on processing dhcp opts
Thanks, that's very helpful - I'll close this one :) ** Changed in: neutron Status: Incomplete => 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/2081161 Title: KeyError: 'ip_version' on processing dhcp opts Status in neutron: Invalid Bug description: release: 2023.1 I'm using the networking-mlnx and ovn mechanism drivers and there is a bad interaction with some of the DHCP options networking-mlnx adds: ``` 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers [req-d65bacb9-884c-4b3d-9e08-3c2f1e192998 req-1a500bb1-5615-491a-ba85-bfe41257a17e f5c0b82c90544eae800299324a3637b8 3ffaeaac91904e0ca02f7aca7c00b81a - - default default] Mechanism driver 'ovn' failed in update_port_postcommit: KeyError: 'ip_version' 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers Traceback (most recent call last): 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/managers.py", line 497, in _call_on_drivers 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers getattr(driver.obj, method_name)(context) 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py", line 886, in update_port_postcommit 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers self._ovn_update_port(context.plugin_context, port, original_port, 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py", line 767, in _ovn_update_port 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers self._ovn_client.update_port(plugin_context, port, 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 644, in update_port 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers port_info, external_ids = self.get_external_ids_from_port(port) 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 510, in get_external_ids_from_port 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers port_info = self._get_port_options(port) 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 344, in _get_port_options 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers dhcpv4_options = self._get_port_dhcp_options(port, const.IP_VERSION_4) 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 219, in _get_port_dhcp_options 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers lsp_dhcp_disabled, lsp_dhcp_opts = utils.get_lsp_dhcp_opts( 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers File "/var/lib/kolla/venv/lib64/python3.9/site-packages/neutron/common/ovn/utils.py", line 274, in get_lsp_dhcp_opts 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers if edo['ip_version'] != ip_version: 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers KeyError: 'ip_version' 2024-08-15 12:14:56.800 37 ERROR neutron.plugins.ml2.managers 2024-08-15 12:14:56.801 37 ERROR neutron.plugins.ml2.plugin [req-d65bacb9-884c-4b3d-9e08-3c2f1e192998 req-1a500bb1-5615-491a-ba85-bfe41257a17e f5c0b82c90544eae800299324a3637b8 3ffaeaac91904e0ca02f7aca7c00b81a - - default default] mechanism_manager.update_port_postcommit failed for port 242c3591-e60d-41d4-811e-c8d0a838158e: neutron.plugins.ml2.common.exceptions.MechanismDriverError ``` I'm not an expert, but I believe the ovn driver would not even attempt bind this port so shouldn't be concerned with dhcp options added by networking-mlnx. I've partially worked around this issue by putting mlnx_infiniband after ovn in the mechanism driver list, but believe I still see this exception on port binding failure. I known networking-mlnx is a little unmaintained and may be doing something weird, but it does seem like the ovn mechanism driver could handle this case more gracefully. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2081161/+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 hel
[Yahoo-eng-team] [Bug 1477684] Re: Instance recreate is not supported
This is super old and the XenAPI driver was removed in 2020: https://review.opendev.org/q/topic:%22remove-xenapi%22+is:merged ** Changed in: nova Status: Confirmed => Invalid -- 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/1477684 Title: Instance recreate is not supported Status in OpenStack Compute (nova): Invalid Bug description: Evacuating a BFV instance involves rebuilding it on a new host. However, the XenAPI Driver doesn't support recreate. Relevant logs: https://gist.github.com/zaina/629dbfb737d7af974a1b To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1477684/+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 1378689] Re: error when rebuilding a instance booted from volume
This was implemented by https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild ** Changed in: nova Status: In Progress => Fix Released -- 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/1378689 Title: error when rebuilding a instance booted from volume Status in OpenStack Compute (nova): Fix Released Bug description: with libvirt driver as compute virt driver, when rebuild a instance booted from a bootable volume, instance will be set to "ERROR" state, the error log in log: libvirtError: Failed to terminate process 8804 with SIGKILL: Device or resource busy To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1378689/+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 2065821] Re: cover job started to fail with Killed
I originally marked my change Related-bug, but I believe all the changes
above have addressed the problem, so will close this bug.
** 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/2065821
Title:
cover job started to fail with Killed
Status in neutron:
Fix Released
Bug description:
Pipeline here:
https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-
cover&project=openstack/neutron
First failure is May 14:
https://zuul.opendev.org/t/openstack/build/6899085a449248ed8b017eb4e9f231ab
In logs, it looks like this:
2024-05-14 16:33:32.050334 | ubuntu-jammy | Implementing implicit namespace
packages (as specified in PEP 420) is preferred to
`pkg_resources.declare_namespace`. See
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
2024-05-14 16:33:32.050424 | ubuntu-jammy | declare_namespace(pkg)
2024-05-14 16:33:32.050451 | ubuntu-jammy |
/home/zuul/src/opendev.org/openstack/neutron/.tox/cover/lib/python3.10/site-packages/pkg_resources/__init__.py:2832:
DeprecationWarning: Deprecated call to
`pkg_resources.declare_namespace('repoze')`.
2024-05-14 16:33:32.050472 | ubuntu-jammy | Implementing implicit namespace
packages (as specified in PEP 420) is preferred to
`pkg_resources.declare_namespace`. See
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
2024-05-14 16:33:32.050490 | ubuntu-jammy | declare_namespace(pkg)
2024-05-14 16:33:32.050516 | ubuntu-jammy |
/home/zuul/src/opendev.org/openstack/neutron/.tox/cover/lib/python3.10/site-packages/pkg_resources/__init__.py:2832:
DeprecationWarning: Deprecated call to
`pkg_resources.declare_namespace('repoze')`.
2024-05-14 16:59:58.794881 | ubuntu-jammy | Implementing implicit namespace
packages (as specified in PEP 420) is preferred to
`pkg_resources.declare_namespace`. See
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
2024-05-14 16:59:58.796083 | ubuntu-jammy | declare_namespace(pkg)
2024-05-14 16:59:58.796171 | ubuntu-jammy | Killed
2024-05-14 17:03:29.030113 | ubuntu-jammy | Ran 20812 tests in 1777.707s
2024-05-14 17:03:29.174365 | ubuntu-jammy | FAILED (id=0, failures=1,
skips=1701)
Could it be that the job no longer has enough memory and gets OOM
killed?
I've compared versions of packages updated between older good and
newer bad runs, and I only see these bumped: sqlalchemy 1.4.51 ->
2.0.29 and alembic 1.9.4 -> 1.13.1.
Different runs have different unit tests reported as failed (all
failed runs claim a single test case failed).
Examples of different failed tests:
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_218/917262/3/check/openstack-
tox-cover/2180cc3/testr_results.html -
neutron.tests.unit.services.network_segment_range.test_plugin.TestNetworkSegmentRange.test_delete_network_segment_range_failed_with_segment_referenced
https://9b86ab5bbc6be76c9905-30f46d6ec556e6b2dd47ea35fedbb1ac.ssl.cf5.rackcdn.com/919699/4/check/openstack-
tox-cover/ce9baa9/testr_results.html -
neutron.tests.unit.services.ovn_l3.test_plugin.OVNL3ExtrarouteTests
.test_floatingip_update_different_port_owner_as_admin
https://6eed35a50c35f284b4d2-bf433abff5f8b85f7f80257b72ac6f67.ssl.cf2.rackcdn.com/919632/1/check/openstack-
tox-cover/3b1c5fa/testr_results.html -
neutron.tests.unit.services.placement_report.test_plugin.PlacementReportPluginTestCases.test__sync_placement_state_legacy
I suspect specific unit test cases are not relevant - the test runner
process dies for some reason and whatever the test it was running at
that moment gets reported as failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2065821/+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
