[Yahoo-eng-team] [Bug 2017748] Re: OVN: ovnmeta namespaces missing during scalability test causing DHCP issues
A customer has the similar issue. Although I can't reproduce this in my local environment. I prepared debdiff for yoga. Our support engineer pointed this out ( patch 2 ) and it makes sense to backport. As you can see the description, it is happening intermittently with high load. the customer also faced this few times and can't reproduce even they want. There are two commits inside the debdiff file [PATCH 1/2] ovn-metadata: Refactor events [PATCH 2/2] Handle creation of Port_Binding with chassis set patch 1 is needed because of massive conflict Above 2023.1 already has above patches. ** Tags added: sts ** Also affects: neutron (Ubuntu) Importance: Undecided Status: New ** Also affects: neutron (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: neutron (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: neutron (Ubuntu) Status: New => Fix Released ** Patch added: "lp2017748_focal_yoga.debdiff" https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/2017748/+attachment/5746530/+files/lp2017748_focal_yoga.debdiff -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2017748 Title: OVN: ovnmeta namespaces missing during scalability test causing DHCP issues Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: New Status in neutron source package in Jammy: New Bug description: Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=2187650 During a scalability test it was noted that a few VMs where having issues being pinged (2 out of ~5000 VMs in the test conducted). After some investigation it was found that the VMs in question did not receive a DHCP lease: udhcpc: no lease, failing FAIL checking http://169.254.169.254/2009-04-04/instance-id failed 1/20: up 181.90. request failed And the ovnmeta- namespaces for the networks that the VMs was booting from were missing. Looking into the ovn-metadata-agent.log: 2023-04-18 06:56:09.864 353474 DEBUG neutron.agent.ovn.metadata.agent [-] There is no metadata port for network 9029c393-5c40-4bf2-beec-27413417eafa or it has no MAC or IP addresses configured, tearing the namespace down if needed _get_provision_params /usr/lib/python3.9/site- packages/neutron/agent/ovn/metadata/agent.py:495 Apparently, when the system is under stress (scalability tests) there are some edge cases where the metadata port information has not yet being propagated by OVN to the Southbound database and when the PortBindingChassisEvent event is being handled and try to find either the metadata port of the IP information on it (which is updated by ML2/OVN during subnet creation) it can not be found and fails silently with the error shown above. Note that, running the same tests but with less concurrency did not trigger this issue. So only happens when the system is overloaded. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2017748/+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 2053297] [NEW] LDAP keystone.exception.DomainNotFound: Could not find domain:
Public bug reported: Openstack version: 2023.1 Deployment tool: kolla-ansible OS: Ubuntu 22.04 Integrating keystone with LDAP for Centralized authentication. # /etc/kolla/config/keystone/domains/keystone.eng.conf # Ansible managed [identity] driver = ldap domain_config_dir = /etc/keystone/domains domain_specific_drivers_enabled = True [assignment] driver = sql [ldap] debug_level = 4095 group_allow_create = False group_allow_delete = False group_allow_update = False group_id_attribute = cn group_member_attribute = memberof group_name_attribute = cn group_objectclass = organizationalUnit group_tree_dn = cn=groups,cn=compat,dc=example,dc=com password = XX project_allow_create = False project_allow_delete = False project_allow_update = False role_allow_create = False role_allow_delete = False role_allow_update = False suffix = dc=example,dc=com tls_cacertfile = /etc/keystone/ssl/ipa-ldap.crt tls_req_cert = allow url = ldaps://ldap.example.com use_dump_member = False use_tls = False user = uid=svc-openstack,cn=users,cn=accounts,dc=example,dc=com user_allow_create = False user_allow_delete = False user_allow_update = False user_enabled_attribute = userAccountControl user_filter = (memberof=cn=openstack-eng,cn=groups,cn=accounts,dc=example,dc=com) user_id_attribute = cn user_mail_attribute = mail user_name_attribute = uid user_objectclass = person user_pass_attribute = password user_tree_dn = cn=users,cn=accounts,dc=example,dc=com When I list all users from ldap domain I can see list of users in output # openstack user list --domain eng +--++ | ID | Name | +--++ | 5941b66ab2dd5c288b9c43af63eac64802e7fcc13f93a39341d0972623dea482 | user1 | | cbadc09bf614aae6cb02ec55a7c0339d23fb23862465006117574856f5a9ea25 | user2 | | b2c2da99373ad98a4b266fdaba5773ad8284e53b6e6d6814d739a671c57036a1 | user3 | | 76c268f25474aad5bad0035bec482ada7ceb94f82d8d46b4973091b120d1b925 | spatel | | 018019fc1b632ea62a339bd6610ef3011dc95aaae01b0b7fa4f72d836c1a816f | user4 | Same time I am seeing this error in keystone.log file. Thought I should report the errors. 2024-02-15 20:41:57.658 22 WARNING keystone.common.password_hashing [None req-01863ce5-e57b-41e9-80ec-e994166b9757 - - - - - -] Truncating password to algorithm specific maximum length 72 characters. 2024-02-15 20:42:03.209 25 WARNING keystone.common.rbac_enforcer.enforcer [None req-4f4495f7-2527-4463-84fe-1d795fcb946e f55d38aca4384bfdb32806d5ca452c66 32f16f689e8445e0bf74c59c57096b3a - - default default] Deprecated policy rules found. Use oslopolicy-policy-generator and oslopolicy-policy-upgrade to detect and resolve deprecated policies in your configuration. 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application [None req-4f4495f7-2527-4463-84fe-1d795fcb946e f55d38aca4384bfdb32806d5ca452c66 32f16f689e8445e0bf74c59c57096b3a - - default default] Could not find domain: eng.: keystone.exception.DomainNotFound: Could not find domain: eng. 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application Traceback (most recent call last): 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/resource/core.py", line 712, in get_domain 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application project = self.driver.get_project(domain_id) 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/resource/backends/sql.py", line 49, in get_project 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application return self._get_project(session, project_id).to_dict() 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/resource/backends/sql.py", line 44, in _get_project 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application raise exception.ProjectNotFound(project_id=project_id) 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application keystone.exception.ProjectNotFound: Could not find project: eng. 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application During handling of the above exception, another exception occurred: 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application Traceback (most recent call last): 2024-02-15 20:42:03.225 25 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 1820, in full_dispatch_request 2024-02-15 20:42:03.225 25 ERROR
[Yahoo-eng-team] [Bug 2053274] [NEW] [ovn] mtu for metadata veth interface is not set
Public bug reported: When using OVN, the `veth` interfaces which get created inside the network namespace (and the other half that goes into the OVS bridge) both do not get an MTU configured for them when they are provisioned. https://github.com/openstack/neutron/blob/stable/zed/neutron/agent/ovn/metadata/agent.py#L589-L594 This can cause some unknown/annoying errors with packets being dropped if a user is hitting large requests on the metadata service, the ideal solution would be to configure the correct MTU for the interface to avoid this issue. ** 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/2053274 Title: [ovn] mtu for metadata veth interface is not set Status in neutron: New Bug description: When using OVN, the `veth` interfaces which get created inside the network namespace (and the other half that goes into the OVS bridge) both do not get an MTU configured for them when they are provisioned. https://github.com/openstack/neutron/blob/stable/zed/neutron/agent/ovn/metadata/agent.py#L589-L594 This can cause some unknown/annoying errors with packets being dropped if a user is hitting large requests on the metadata service, the ideal solution would be to configure the correct MTU for the interface to avoid this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2053274/+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 2019190] Re: [SRU][RBD] Retyping of in-use boot volumes renders instances unusable (possible data corruption)
This bug was fixed in the package cinder - 2:23.0.0-0ubuntu1.1 --- cinder (2:23.0.0-0ubuntu1.1) mantic; urgency=medium [ Corey Bryant ] * d/gbp.conf: Create stable/2023.2 branch. * d/gbp.conf, .launchpad.yaml: Sync from cloud-archive-tools for bobcat. [ Edward Hope-Morley ] * revert driver assister volume retype (LP: #2019190) - d/p/0001-Revert-Driver-assisted-migration-on-retype-when-it-s.patch -- James Page Thu, 25 Jan 2024 16:33:13 + ** Changed in: cinder (Ubuntu Mantic) Status: Fix Committed => 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/2019190 Title: [SRU][RBD] Retyping of in-use boot volumes renders instances unusable (possible data corruption) Status in Cinder: New Status in Cinder wallaby series: New Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive antelope series: Fix Committed Status in Ubuntu Cloud Archive bobcat series: Fix Committed Status in Ubuntu Cloud Archive caracal series: Fix Released Status in Ubuntu Cloud Archive yoga series: Fix Committed Status in Ubuntu Cloud Archive zed series: Fix Committed Status in OpenStack Compute (nova): Invalid Status in cinder package in Ubuntu: Fix Released Status in cinder source package in Jammy: Fix Committed Status in cinder source package in Lunar: Won't Fix Status in cinder source package in Mantic: Fix Released Status in cinder source package in Noble: Fix Released Bug description: [Impact] See bug description for full details but short summary is that a patch landed in Wallaby release that introduced a regression whereby retyping an in-use volume leaves the attached volume in an inconsistent state with potential for data corruption. Result is that a vm does not receive updated connection_info from Cinder and will keep pointing to the old volume, even after reboot. [Test Plan] * Deploy Openstack with two Cinder RBD storage backends (different pools) * Create two volume types * Boot a vm from volume: openstack server create --wait --image jammy --flavor m1.small --key-name testkey --nic net-id=8c74f1ef-9231-46f4-a492-eccdb7943ecd testvm --boot-from-volume 10 * Retype the volume to type B: openstack volume set --type typeB --retype-policy on-demand * Go to compute host running vm and check that the vm is now copying data to the new location e.g. b68be47d-f526-4f98-a77b-a903bf8b6c65 which will eventually settle and change to: b68be47d-f526-4f98-a77b-a903bf8b6c65 * And lastly a reboot of the vm should be successfull. [Regression Potential] Given that the current state is potential data corruption and the patch will fix this by successfully refreshing connection info I do not see a regression potential. It is in fact fixing a regression. - While trying out the volume retype feature in cinder, we noticed that after an instance is rebooted it will not come back online and be stuck in an error state or if it comes back online, its filesystem is corrupted. ## Observations Say there are the two volume types `fast` (stored in ceph pool `volumes`) and `slow` (stored in ceph pool `volumes.hdd`). Before the retyping we can see that the volume for example is present in the `volumes.hdd` pool and has a watcher accessing the volume. ```sh [ceph: root@mon0 /]# rbd ls volumes.hdd volume-81cfbafc-4fbb-41b0-abcb-8ec7359d0bf9 [ceph: root@mon0 /]# rbd status volumes.hdd/volume-81cfbafc-4fbb-41b0-abcb-8ec7359d0bf9 Watchers: watcher=[2001:XX:XX:XX::10ad]:0/3914407456 client.365192 cookie=140370268803456 ``` Starting the retyping process using the migration policy `on-demand` for that volume either via the horizon dashboard or the CLI causes the volume to be correctly transferred to the `volumes` pool within the ceph cluster. However, the watcher does not get transferred, so nobody is accessing the volume after it has been transferred. ```sh [ceph: root@mon0 /]# rbd ls volumes volume-81cfbafc-4fbb-41b0-abcb-8ec7359d0bf9 [ceph: root@mon0 /]# rbd status volumes/volume-81cfbafc-4fbb-41b0-abcb-8ec7359d0bf9 Watchers: none ``` Taking a look at the libvirt XML of the instance in question, one can see that the `rbd` volume path does not change after the retyping is completed. Therefore, if the instance is restarted nova will not be able to find its volume preventing an
[Yahoo-eng-team] [Bug 2046549] Re: hyperv reenlightenment can break live-migration
Reviewed: https://review.opendev.org/c/openstack/nova/+/904183
Committed:
https://opendev.org/openstack/nova/commit/e618e78edc6293d248a5fa2eb63b3fa636250fca
Submitter: "Zuul (22348)"
Branch:master
commit e618e78edc6293d248a5fa2eb63b3fa636250fca
Author: songjie
Date: Mon Dec 25 16:59:36 2023 +0800
libvirt: stop enabling hyperv feature reenlightenment
The 'reenlightenment' hyperv enlightenment will cause
instances live-migration to fail (KVM currently doesn’t
fully support reenlightenment notifications, see
www.qemu.org/docs/master/system/i386/hyperv.html),
so don't enable it now.
Change-Id: I6821819450bc96e4304125ea3b76a0e462e6e33f
Closes-Bug: #2046549
Related-Bug: #2009280
** 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/2046549
Title:
hyperv reenlightenment can break live-migration
Status in OpenStack Compute (nova):
Fix Released
Bug description:
With ZED nova enabled some new hyperv settings for instances with
os_type="windows" property
(https://opendev.org/openstack/nova/commit/57ab45323cf5617ebd2decd757e708673d949a8f).
Enabling the reenlightenment setting can lead to unmigrateable VMs.
QEMU currently does not support full re-enlightenment notifications (see
https://www.qemu.org/docs/master/system/i386/hyperv.html).
Windows VMs which have hyperv or WSL enabled make use of that feature,
but qemu can only migrate them if a tsc-frequency is set. The frequency
setting however is not applied and when set would restrict the target hv
to support the exact frequency.
Trying to migrate instances with reenlightenment enabled will fail
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/eventlet/hubs/hub.py", line
476, in fire_timers
timer()
File
"/usr/local/lib/python3.10/dist-packages/eventlet/hubs/timer.py", line 59, in
__call__
cb(*args, **kw)
File "/usr/local/lib/python3.10/dist-packages/eventlet/event.py", line 175,
in _do_send
waiter.switch(result)
File "/usr/local/lib/python3.10/dist-packages/eventlet/greenthread.py",
line 221, in main
result = function(*args, **kwargs)
File
"/usr/local/lib/python3.10/dist-packages/nova/utils.py", line 656, in
context_wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/nova/virt/libvirt/driver.py",
line 10214, in _live_migration_operation
with excutils.save_and_reraise_exception():
File "/usr/local/lib/python3.10/dist-packages/oslo_utils/excutils.py", line
227, in __exit__
self.force_reraise()
File "/usr/local/lib/python3.10/dist-packages/oslo_utils/excutils.py", line
200, in force_reraise
raise self.value
File "/usr/local/lib/python3.10/dist-packages/nova/virt/libvirt/driver.py",
line 10203, in _live_migration_operation
guest.migrate(self._live_migration_uri(dest),
File "/usr/local/lib/python3.10/dist-packages/nova/virt/libvirt/guest.py",
line 642, in migrate
self._domain.migrateToURI3(
File "/usr/local/lib/python3.10/dist-packages/eventlet/tpool.py", line 193,
in doit
result = proxy_call(self._autowrap, f, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/eventlet/tpool.py", line 151,
in proxy_callrv
= execute(f, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/eventlet/tpool.py", line 132,
in execute
six.reraise(c, e, tb)
File "/usr/lib/python3/dist-packages/six.py", line 719, in reraise
raise value
File "/usr/local/lib/python3.10/dist-packages/eventlet/tpool.py", line 86,
in tworker
rv = meth(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/libvirt.py", line 2157, in
migrateToURI3
raise libvirtError('virDomainMigrateToURI3() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor:
2023-12-14T09:05:01.441735Z qemu-system-x86_64: Guest enabled
re-enlightenment notifications, 'tsc-frequency=' has to be specified
2023-12-14T09:05:01.441854Z qemu-system-x86_64: error while loading state for
instance 0x0 of device 'cpu'
2023-12-14T09:05:01.448766Z qemu-system-x86_64: load of migration failed:
Invalid argument
Adding the tsc clock or removing the hypver reenlightenment will make
migration work again.
eg.:
A related bug for windows enlightenments targets evmcs:
https://bugs.launchpad.net/nova/+bug/2009280
To manage notifications about this bug go
[Yahoo-eng-team] [Bug 2009280] Re: evmc not supported on AMD processors but is enabled by default for "windows" instances
Reviewed: https://review.opendev.org/c/openstack/nova/+/899776 Committed: https://opendev.org/openstack/nova/commit/86a35e97d286cbb6e23f8cc7bec5a05f022da0cb Submitter: "Zuul (22348)" Branch:master commit 86a35e97d286cbb6e23f8cc7bec5a05f022da0cb Author: Artom Lifshitz Date: Tue Oct 31 22:52:50 2023 -0400 libvirt: Stop unconditionally enabling evmcs In I008841988547573878c4e06e82f0fa55084e51b5 we started enabling a bunch of libvirt enlightenments for Windows unconditionally. Turns out, the `evmcs` enlightenment only works on Intel hosts, and we broke the ability to run Windows guests on AMD machines. Until we become smarter about conditionally enabling evmcs (with something like traits for host CPU features), just stop enabling it at all. Change-Id: I2ff4fdecd9dc69de283f0e52e07df1aeaf0a9048 Closes-bug: 2009280 ** 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/2009280 Title: evmc not supported on AMD processors but is enabled by default for "windows" instances Status in OpenStack Compute (nova): Fix Released Bug description: on AMD Processors it is known that QEMU does not not support hv-evmc but as of notes/update-libvirt-enlightenments-for-windows-23abea98cc1db667.yaml it was enabled There is no way that I can see to single out this flag and nova should check if the remote CPU is AMD and disable this enablement. You can test this on any AMD machine with "qemu-system-x86_64 --nographic -cpu host,hv_relaxed,hv_vapic,hv_spinlocks=8191,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv_frequencies,hv_time,hv_evmcs --enable-kvm" and it will throw a critical error of "Hyper-V enlightened VMCS (hv-evmcs) is not supported by kernel" Here are example logs that are thrown by nova when trying to start the instance, the instance was set to os_type: windows to have it throw this. This was tested on Zed with a AMD EYPC 7702 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [None req-2172765f-0769-4b82-88fa-3cd68144ee42 ff259b03efc14bee83c881bc4920a12d a69aa169729a4dbea0d9b9683072260d - - default default] [instance: d416180c-cd56-4830-9787-3bb4953d9b02] Failed to build and run instance: libvirt.libvirt] 2023-03-04T20:57:46.694416Z qemu-kvm: warning: This feature depends on other features that were not requested: CPUID.800AH:EDX.tsc-scale [bit 4] 2023-03-04T20:57:46.694441Z qemu-kvm: warning: This feature depends on other features that were not requested: CPUID.800AH:EDX.vmcb-clean [bit 5] 2023-03-04T20:57:46.694465Z qemu-kvm: warning: This feature depends on other features that were not requested: CPUID.800AH:EDX.pause-filter [bit 10] 2023-03-04T20:57:46.694489Z qemu-kvm: warning: This feature depends on other features that were not requested: CPUID.800AH:EDX.pfthreshold [bit 12] 2023-03-04T20:57:46.694513Z qemu-kvm: warning: This feature depends on other features that were not requested: CPUID.800AH:EDX.svme-addr-chk [bit 28] 2023-03-04T20:57:46.694549Z qemu-kvm: Hyper-V enlightened VMCS (hv-evmcs) is not supported by kernel 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] Traceback (most recent call last): 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] File "/var/lib/kolla/venv/lib/python3.9/site-packages/nova/compute/manager.py", line 2517, in _build_and_run_instance 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] self.driver.spawn(context, instance, image_meta, 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] File "/var/lib/kolla/venv/lib/python3.9/site-packages/nova/virt/libvirt/driver.py", line 4366, in spawn 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] self._create_guest_with_network( 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] File "/var/lib/kolla/venv/lib/python3.9/site-packages/nova/virt/libvirt/driver.py", line 7724, in _create_guest_with_network 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] self._cleanup( 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] File "/var/lib/kolla/venv/lib/python3.9/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] self.force_reraise() 2023-03-04 15:57:47.721 7 ERROR nova.compute.manager [instance: d416180c-cd56-4830-9787-3bb4953d9b02] File
[Yahoo-eng-team] [Bug 2053227] [NEW] [ovn-octavia-provider] ovn-octavia-provider-functional-master is broken by ovn build failure
Public bug reported: The ovn-octavia-provider-functional-master job consistently fails during set up. The log indicates ovn build is failing. example: https://zuul.opendev.org/t/openstack/build/65fafcb26fdb4b9b97d9ce481f70037e ``` ... gcc -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./ovn -I ./include -I ./lib -I ./lib -I /home/zuul/src/opendev.org/openstack/ovs/include -I /home/zuul/src/opendev.org/openstack/ovs/include -I /home/zuul/src/opendev.org/openstack/ovs/lib -I /home/zuul/src/opendev.org/openstack/ovs/lib -I /home/zuul/src/opendev.org/openstack/ovs -I /home/zuul/src/opendev.org/openstack/ovs-Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -fno-strict-aliasing -Wswitch-bool -Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare -Wshift-negative-value -Wduplicated-cond -Wshadow -Wmultistatement-macros -Wcast-align=strict -g -O2 -MT controller/physical.o -MD -MP -MF $depbase.Tpo -c -o controller/physical.o controller/physical.c &&\ mv -f $depbase.Tpo $depbase.Po controller/ofctrl.c: In function ‘ofctrl_inject_pkt’: controller/ofctrl.c:3048:5: error: too many arguments to function ‘flow_compose’ 3048 | flow_compose(, , NULL, 64, false); | ^~~~ In file included from /home/zuul/src/opendev.org/openstack/ovs/lib/dp-packet.h:34, from controller/ofctrl.c:21: /home/zuul/src/opendev.org/openstack/ovs/lib/flow.h:129:6: note: declared here 129 | void flow_compose(struct dp_packet *, const struct flow *, | ^~~~ make[1]: *** [Makefile:2369: controller/ofctrl.o] Error 1 make[1]: *** Waiting for unfinished jobs controller/pinctrl.c: In function ‘pinctrl_ip_mcast_handle_igmp’: controller/pinctrl.c:5488:54: error: ‘MCAST_GROUP_IGMPV1’ undeclared (first use in this function) 5488 | port_key_data, MCAST_GROUP_IGMPV1); | ^~ controller/pinctrl.c:5488:54: note: each undeclared identifier is reported only once for each function it appears in controller/pinctrl.c:5487:13: error: too many arguments to function ‘mcast_snooping_add_group4’ 5487 | mcast_snooping_add_group4(ip_ms->ms, ip4, IP_MCAST_VLAN, | ^ In file included from controller/ip-mcast.h:19, from controller/pinctrl.c:64: /home/zuul/src/opendev.org/openstack/ovs/lib/mcast-snooping.h:190:6: note: declared here 190 | bool mcast_snooping_add_group4(struct mcast_snooping *ms, ovs_be32 ip4, | ^ controller/pinctrl.c:5493:54: error: ‘MCAST_GROUP_IGMPV2’ undeclared (first use in this function) 5493 | port_key_data, MCAST_GROUP_IGMPV2); | ^~ controller/pinctrl.c:5492:13: error: too many arguments to function ‘mcast_snooping_add_group4’ 5492 | mcast_snooping_add_group4(ip_ms->ms, ip4, IP_MCAST_VLAN, | ^ In file included from controller/ip-mcast.h:19, from controller/pinctrl.c:64: /home/zuul/src/opendev.org/openstack/ovs/lib/mcast-snooping.h:190:6: note: declared here 190 | bool mcast_snooping_add_group4(struct mcast_snooping *ms, ovs_be32 ip4, | ^ make[1]: *** [Makefile:2369: controller/pinctrl.o] Error 1 make[1]: Leaving directory '/home/zuul/src/opendev.org/openstack/ovn' make: *** [Makefile:1528: all] Error 2 ``` ** Affects: neutron Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Tags: ovn-octavia-provider ** Changed in: neutron Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Tags added: ovn-octavia-provider -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2053227 Title: [ovn-octavia-provider] ovn-octavia-provider-functional-master is broken by ovn build failure Status in neutron: In Progress Bug description: The ovn-octavia-provider-functional-master job consistently fails during set up. The log indicates ovn build is failing. example: https://zuul.opendev.org/t/openstack/build/65fafcb26fdb4b9b97d9ce481f70037e ``` ... gcc -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./ovn -I ./include -I ./lib -I ./lib -I /home/zuul/src/opendev.org/openstack/ovs/include -I /home/zuul/src/opendev.org/openstack/ovs/include -I /home/zuul/src/opendev.org/openstack/ovs/lib -I
