[Yahoo-eng-team] [Bug 1955773] Re: Recursion error when generating documentation for Senlin
Reviewed: https://review.opendev.org/c/openstack/horizon/+/822212 Committed: https://opendev.org/openstack/horizon/commit/b8cc0043d46318c7e11952109450587bee9567ab Submitter: "Zuul (22348)" Branch:master commit b8cc0043d46318c7e11952109450587bee9567ab Author: Erik Olof Gunnar Andersson Date: Fri Dec 17 18:32:03 2021 -0800 Fix maximum recursion depth error when generating documentation Troubleshooting an issue with Senlin documentation, > RecursionError: maximum recursion depth exceeded in __instancecheck__ it turns out that attrs['base_options'] creates a recursive reference when no base classes have 'base_options'. This happens when BaseAction is created. Closes-Bug: #1955773 Change-Id: I2724f07339134b3e06b7ea925939bf7072162106 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1955773 Title: Recursion error when generating documentation for Senlin Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Hitting a recursion error when generating documentation for the senlin-dashboard that seems to be indirectly caused by Horizon. > maximum recursion depth exceeded in __instancecheck__ e.g. https://review.opendev.org/c/openstack/senlin-dashboard/+/787090 I wrote a simple fix for this, we could probably change how senlin-dashboard generates documentation as well, but I feel like senlin isn't doing anything that should be causing this type of behavior. https://review.opendev.org/c/openstack/horizon/+/822212 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1955773/+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 1957941] Re: test_network_basic_ops failing on centos-8-stream job
Thanks yatin. Marking invalid for tempest as nothing to do in Tempest. ** Changed in: tempest 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/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in neutron: Triaged Status in tempest: Invalid Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1957941/+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 1956745] Re: [ovn-octavia-provider] Load Balancer remained with ACTIVE state even with PENDING_UPDATE listener
Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/823544 Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/4d01470f5e397bb6de1b10db9f839fa72697ff6b Submitter: "Zuul (22348)" Branch:master commit 4d01470f5e397bb6de1b10db9f839fa72697ff6b Author: Luis Tomas Bolivar Date: Wed Jan 5 15:48:57 2022 +0100 Set listeners back to ACTIVE upon pool/member action failures This patch ensure the listeners are set back from PENDING_UPDATE to ACTIVE in case of member or pool update failure. Closes-Bug: #1956745 Change-Id: I95860ae305c3d0c10859afb972d000328e23d614 ** 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/1956745 Title: [ovn-octavia-provider] Load Balancer remained with ACTIVE state even with PENDING_UPDATE listener Status in neutron: Fix Released Bug description: Description of problem: The Load Balancer remained with ACTIVE and ONLINE state even when the listener had provisioning_status PENDING_UPDATE and the pool was with ERROR, what made the load-balancer to be considered functional by Kuryr and a load-balancer member removal was attempt without success as pool was immutable: 2021-11-03 17:04:53.893 1 ERROR kuryr_kubernetes.handlers.logging openstack.exceptions.ConflictException: ConflictException: 409: Client Error for url: https://10.x.x.x:13876/v2.0/lbaas/po ols/302709f7-d122-49d7-9d05-8e57ccf2ad11/members/214e892a-4e25-46ce-8bba-9ae005304931, Pool 302709f7-d122-49d7-9d05-8e57ccf2ad11 is immutable and cannot be updated. 2021-11-03 17:04:53.893 1 ERROR kuryr_kubernetes.handlers.logging (shiftstack) [stack@undercloud-0 ~]$ openstack loadbalancer show 8d03213c-ab26-4391-9d26-4878fa6b5d02 +-+---+ | Field | Value | +-+---+ | admin_state_up | True | | created_at | 2021-11-02T05:21:15 | | description | | | flavor_id | None | | id | 8d03213c-ab26-4391-9d26-4878fa6b5d02 | | listeners | 39f36082-3a07-44c0-9b00-41ba12db49fa | | name| openshift-marketplace/community-operators | | operating_status| ONLINE| | pools | 302709f7-d122-49d7-9d05-8e57ccf2ad11 | | project_id | fd0d6a21436d4ff987682c3a0419569d | | provider| ovn | | provisioning_status | ACTIVE| | updated_at | 2021-11-02T13:45:52 | | vip_address | 172.30.237.127| | vip_network_id | f738aa91-61e1-4571-8eac-f3979164393f | | vip_port_id | 72502dfe-e6f8-4e9b-9f00-b846bcf693f8 | | vip_qos_policy_id | None | | vip_subnet_id | 14d2bae5-7de6-4f77-882b-1d5c919251fc | +-+---+ (shiftstack) [stack@undercloud-0 ~]$ openstack loadbalancer listener show 39f36082-3a07-44c0-9b00-41ba12db49fa +-+-+ | Field | Value | +-+-+ | admin_state_up | True | | connection_limit| -1 | | created_at | 2021-11-02T05:21:44 | | default_pool_id | 302709f7-d122-49d7-9d05-8e57ccf2ad11 | | default_tls_container_ref | None | | description | | | id | 39f36082-3a07-44c0-9b00-41ba12db49fa | | insert_headers | None | | l7policies | | | loadbalancers | 8d03213c-ab26-4391-9d26-4878fa6b5d02 | | name| openshift-marketplace/community-operators:TCP:50051 | | operating_status| ONLINE | | project_id | fd0d6a21436d4ff987682c3a0419569d
[Yahoo-eng-team] [Bug 1946771] Re: Doc on microversions lacks hint on creating folder in api-samples
Reviewed: https://review.opendev.org/c/openstack/nova/+/813672 Committed: https://opendev.org/openstack/nova/commit/6c5636baab934c9c404810a6ba2e7aed35ad2657 Submitter: "Zuul (22348)" Branch:master commit 6c5636baab934c9c404810a6ba2e7aed35ad2657 Author: Jan Hartkopf Date: Tue Oct 19 18:44:16 2021 +0200 ensure samples folder exists for microversion When adding a microversion, a new corresponding folder for auto-generated samples is required. However, the folder has to be created manually for the generation to succeed. With this change, it is ensured that the folder is present, removing manual interaction. Closes-Bug: #1946771 Change-Id: I18f2e509f8c1ae3ad5866b568afc6e0c341e5c3e Signed-off-by: Jan Hartkopf ** 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/1946771 Title: Doc on microversions lacks hint on creating folder in api-samples Status in OpenStack Compute (nova): Fix Released Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. The documentation on API Microversions (https://docs.openstack.org/nova/latest/contributor/microversions.html#other-necessary-changes) lacks a hint that the contributor must create the subfolder with the new microversion in doc/api-samples/*/$NEW_MICROVERSION in order for the samples to be rendered as JSON files by `tox -e api-samples`. i.e when adding a new microversion `v2.91` for servers I would need to create `doc/api-samples/servers/v2.91?`. Apart from this documentation hint one might argue that the tox env could check for this consistency and give the contributor a proper and helpful error. --- Release: 24.1.0.dev28 on 2020-04-10 11:42:50 SHA: 0a8f3e954485d2a6d80b80da50745cb7b0dbd048 Source: https://opendev.org/openstack/nova/src/doc/source/contributor/microversions.rst URL: https://docs.openstack.org/nova/latest/contributor/microversions.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1946771/+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 1958149] [NEW] ha backup router ipv6 accept_ra broken
Public bug reported: When we restart the neutron-l3-agent we observe that backup routers start accepting router advertisements. This leads to routes inside the router namespace which expire. e.g.: $ ip netns exec qrouter-a5f7fb32-3e30-4e15-89f9-4ae888c2cac6 ip -6 r x:x:1002:1::/64 dev qr-72f85121-ce proto kernel metric 256 expires 86355sec pref medium x:x:1002:1::/64 dev qr-4e84792f-aa proto kernel metric 256 expires 86355sec pref medium fe80::/64 dev ha-9d085c9d-15 proto kernel metric 256 pref medium default via fe80::f816:3eff:fed3:3fa6 dev qr-4e84792f-aa proto ra metric 1024 expires 255sec hoplimit 64 pref medium default via fe80::f816:3eff:fed3:3fa6 dev qr-72f85121-ce proto ra metric 1024 expires 255sec hoplimit 64 pref medium When we now failover to such a backup router, the kernel does not create the necessary directly attached routes because they already exist. The problem is that those routes expire and because we are now a master router the routes do not refresh from the router advertisement anymore and expire after 24h which breaks ipv6 for those routers. After we dug a bit deeper into this issue we found that the function [1] that disables the accept_ra on the backup routers always returns false. So backup routers never get their router advertisement disabled. master router: $ ip netns exec qrouter-92ed5c1f-c705-4ab9-a0e1-56e905d43abd sysctl net.ipv6.conf.qr-c7eb60ab-f1.accept_ra net.ipv6.conf.qr-c7eb60ab-f1.accept_ra = 1 backup router: $ ip netns exec qrouter-92ed5c1f-c705-4ab9-a0e1-56e905d43abd sysctl net.ipv6.conf.qr-c7eb60ab-f1.accept_ra net.ipv6.conf.qr-c7eb60ab-f1.accept_ra = 1 [1] https://github.com/openstack/neutron/blob/master/neutron/agent/l3/ha_router.py#L318 ** Affects: neutron Importance: Undecided Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1958149 Title: ha backup router ipv6 accept_ra broken Status in neutron: In Progress Bug description: When we restart the neutron-l3-agent we observe that backup routers start accepting router advertisements. This leads to routes inside the router namespace which expire. e.g.: $ ip netns exec qrouter-a5f7fb32-3e30-4e15-89f9-4ae888c2cac6 ip -6 r x:x:1002:1::/64 dev qr-72f85121-ce proto kernel metric 256 expires 86355sec pref medium x:x:1002:1::/64 dev qr-4e84792f-aa proto kernel metric 256 expires 86355sec pref medium fe80::/64 dev ha-9d085c9d-15 proto kernel metric 256 pref medium default via fe80::f816:3eff:fed3:3fa6 dev qr-4e84792f-aa proto ra metric 1024 expires 255sec hoplimit 64 pref medium default via fe80::f816:3eff:fed3:3fa6 dev qr-72f85121-ce proto ra metric 1024 expires 255sec hoplimit 64 pref medium When we now failover to such a backup router, the kernel does not create the necessary directly attached routes because they already exist. The problem is that those routes expire and because we are now a master router the routes do not refresh from the router advertisement anymore and expire after 24h which breaks ipv6 for those routers. After we dug a bit deeper into this issue we found that the function [1] that disables the accept_ra on the backup routers always returns false. So backup routers never get their router advertisement disabled. master router: $ ip netns exec qrouter-92ed5c1f-c705-4ab9-a0e1-56e905d43abd sysctl net.ipv6.conf.qr-c7eb60ab-f1.accept_ra net.ipv6.conf.qr-c7eb60ab-f1.accept_ra = 1 backup router: $ ip netns exec qrouter-92ed5c1f-c705-4ab9-a0e1-56e905d43abd sysctl net.ipv6.conf.qr-c7eb60ab-f1.accept_ra net.ipv6.conf.qr-c7eb60ab-f1.accept_ra = 1 [1] https://github.com/openstack/neutron/blob/master/neutron/agent/l3/ha_router.py#L318 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1958149/+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 1958075] Re: The fixtures library is missing from requirements.txt
Reviewed: https://review.opendev.org/c/openstack/nova/+/824830 Committed: https://opendev.org/openstack/nova/commit/33bc5c09f576680d150435fb7ad435b23e778316 Submitter: "Zuul (22348)" Branch:master commit 33bc5c09f576680d150435fb7ad435b23e778316 Author: Takashi Kajinami Date: Sun Jan 16 23:30:41 2022 +0900 Add fixtures to requirements The commit 887c445a7a6a17b92a37b6ed1dcdcc7dd009f65d made the nova.utils module dependent on the fixtures library but the change missed updating requirements and the fixtures library is not installed automatically. This change migrates the fixtures library from test-requirements.txt to requirements.txt so that the library is installed without test codes. Closes-Bug: #1958075 Change-Id: I712f88fc1b6053fe6d1f13e708f3bd8874452a8f ** 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/1958075 Title: The fixtures library is missing from requirements.txt Status in OpenStack Compute (nova): Fix Released Bug description: Description === The following change[1] made the nova.utils module depend on the fixtures library. [1] https://review.opendev.org/c/openstack/nova/+/824280 However the fixtures library is listed only in test-requirements.txt and is not yet listed in requirements.txt . Because of this the library is not installed in normal deployment and the `nova-manage api_db sync` command fails with the following error. Traceback (most recent call last): File "/usr/bin/nova-manage", line 6, in from nova.cmd.manage import main File "/usr/lib/python3.6/site-packages/nova/cmd/manage.py", line 49, in from nova.cmd import common as cmd_common File "/usr/lib/python3.6/site-packages/nova/cmd/common.py", line 26, in import nova.db.main.api File "/usr/lib/python3.6/site-packages/nova/db/main/api.py", line 45, in from nova import block_device File "/usr/lib/python3.6/site-packages/nova/block_device.py", line 26, in from nova import utils File "/usr/lib/python3.6/site-packages/nova/utils.py", line 32, in import fixtures ModuleNotFoundError: No module named 'fixtures' This issue was initially detected in litmus jobs in puppet repos[2]. These jobs uses rdo packages which define dependencies based on requirements.txt [2] example: https://zuul.opendev.org/t/openstack/build/e086ca3375714860ae463b7a1d9b1bab Steps to reproduce == Expected result === Actual result = Environment === Logs & Configs == To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1958075/+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 1958128] [NEW] Neutron l3 agent keeps restarting (Ubuntu)
Public bug reported: After following neutron install guide, when trying to create a floating IP, the request succeeded, but the floating IP never became reachable. Looking at neutron-l3-agent status, I could see that it was restarting every 2 seconds, failing with an exception of 'file not found /etc/neutron/fwaas_driver.ini'. As a temporary fix, I touched the file to create an empty one, and the service started without any errors and the floating IP started working. My configuration is exactly the one provided in the install guide, I didn't change anything. Maybe the documentation should contain a step to avoid this issue ? - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on OFTC --- Release: 19.1.1.dev10 on 2019-08-21 16:09:09 SHA: d202e323d7f03edc56add8e83aeb9cddbbbce895 Source: https://opendev.org/openstack/neutron/src/doc/source/install/controller-install-ubuntu.rst URL: https://docs.openstack.org/neutron/xena/install/controller-install-ubuntu.html ** Affects: neutron Importance: Undecided Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1958128 Title: Neutron l3 agent keeps restarting (Ubuntu) Status in neutron: New Bug description: After following neutron install guide, when trying to create a floating IP, the request succeeded, but the floating IP never became reachable. Looking at neutron-l3-agent status, I could see that it was restarting every 2 seconds, failing with an exception of 'file not found /etc/neutron/fwaas_driver.ini'. As a temporary fix, I touched the file to create an empty one, and the service started without any errors and the floating IP started working. My configuration is exactly the one provided in the install guide, I didn't change anything. Maybe the documentation should contain a step to avoid this issue ? - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on OFTC --- Release: 19.1.1.dev10 on 2019-08-21 16:09:09 SHA: d202e323d7f03edc56add8e83aeb9cddbbbce895 Source: https://opendev.org/openstack/neutron/src/doc/source/install/controller-install-ubuntu.rst URL: https://docs.openstack.org/neutron/xena/install/controller-install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1958128/+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 1948706] Re: Glance cannot remove image if Nova boots instance from image with incorrect signature.
Reviewed: https://review.opendev.org/c/openstack/nova/+/815347
Committed:
https://opendev.org/openstack/nova/commit/43bca185fe2d00bb70d7486fa6c6a0b9eda1fc17
Submitter: "Zuul (22348)"
Branch:master
commit 43bca185fe2d00bb70d7486fa6c6a0b9eda1fc17
Author: Mitya_Eremeev
Date: Thu Nov 11 18:52:11 2021 +0300
Close Glance image if downloading failed.
If downloding of Glance image failed we should
close iterator of image body.
Otherwise Glance is unable to delete the image.
Change-Id: I193df2fcbf2588c10be953eb4e9eef4609b6286f
Closes-Bug: 1948706
** 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/1948706
Title:
Glance cannot remove image if Nova boots instance from image with
incorrect signature.
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Description
===
Nova is configured to verify glance images:
[glance]
verify_glance_signatures=true
Glance backend is Ceph.
Steps to reproduce
==
1. create glance image with proper signature
2. update glance image with incorrect signature
3. try to boot instance from the glance image with incorrect signature.
Boot fails because Nova checks signature and verification fails.
It's correct behavior.
barbican_tempest_plugin.tests.scenario.test_image_signing.ImageSigningTest.test_signed_image_upload_boot_failure[compute,id-74f022d6-a6ef-4458-96b7-541deadacf99,image,smoke]
-
Captured traceback:
~~~
Traceback (most recent call last):
File
"/var/lib/openstack/lib/python3.6/site-packages/tempest/lib/services/image/v2/images_client.py",
line 103, in delete_image
resp, _ = self.delete(url)
File
"/var/lib/openstack/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 330, in delete
return self.request('DELETE', url, extra_headers, headers, body)
File
"/var/lib/openstack/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 710, in request
self._error_checker(resp, resp_body)
File
"/var/lib/openstack/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 831, in _error_checker
raise exceptions.Conflict(resp_body, resp=resp)
tempest.lib.exceptions.Conflict: Conflict with state of target resource
Details: {'message': 'Image c321f6be-a4d3-42d2-bc3f-f0ea913b83b7 could not be
deleted because it is in use: The image cannot be deleted because it is in use
through the backend store outside of Glance.\n\n\n', 'code': '409
Conflict', 'title': 'Conflict'}
4. Delete the glance image right after failed instance boot.
Expected result
===
Glance image was deleted successfully.
Actual result
=
Glance cannot be deleted.
In Glance backend we see that there are watchers that protect glance image
from deletion:
# rbd rm --pool images-hdd c321f6be-a4d3-42d2-bc3f-f0ea913b83b7
2021-10-15T13:25:03.862+ 7f36b98c8700 -1 librbd::image::PreRemoveRequest:
0x562785d77a50 check_image_watchers: image has watchers - not removing
Removing image: 0% complete...failed.
rbd: error: image still has watchers
This means the image is still open or the client using it crashed. Try again
after closing/unmapping it or waiting 30s for the crashed client to timeout.
# rbd status --pool images-hdd c321f6be-a4d3-42d2-bc3f-f0ea913b83b7
Watchers:
watcher=10.10.0.89:0/729945307 client.374098 cookie=140684808072160
The behavior is reproduced by tempest test:
https://github.com/openstack/barbican-tempest-plugin/blob/master/barbican_tempest_plugin/tests/scenario/test_image_signing.py#L67
Environment
===
1. Openstack version: Victoria
2. Hypervisor: KVM + libvirt
3. Glance storage: Ceph, Nova storage: local.
4. Networking: Neutron with OVS
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1948706/+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 1949496] Re: [OVN] Check OVN support virtual port type
Reviewed: https://review.opendev.org/c/openstack/neutron/+/816383 Committed: https://opendev.org/openstack/neutron/commit/58feb88853e9f12deaedb612d5855f3d80607e40 Submitter: "Zuul (22348)" Branch:master commit 58feb88853e9f12deaedb612d5855f3d80607e40 Author: Rodolfo Alonso Hernandez Date: Tue Nov 2 17:36:16 2021 + [OVN] Check if OVN SB supports virtual ports Added a check for OVN SB schema, looking for "virtual_parent" in "Port_Binding" table (added in OVN SB schema 2.5). This patch removes the code to support OVN without virtual ports. It is assumed that "virtual_parent" field is present in "Port_Binding" table. Closes-Bug: #1949496 Change-Id: I3d01f58dca570537b5e754b331ca4809a7161ae2 ** 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/1949496 Title: [OVN] Check OVN support virtual port type Status in neutron: Fix Released Bug description: This feature was added to OVN in [1]. OVN SB schema version: 2.5.0 [1]https://github.com/ovn- org/ovn/commit/054f4c85c413e20d893e10ba053ec52ac15db49c To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1949496/+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 1957021] Re: openstack xena documenation has wrong neutron service name to start
Seems you following wrong documentation for CentOS Stream. You need to refer https://docs.openstack.org/neutron/xena/install/install-rdo.html instead of https://docs.openstack.org/neutron/xena/install/install- obs.html, The later one is for OpenSUSE. Marking the bug as invalid. https://docs.openstack.org/neutron/xena/install/install-rdo.html correctly describes the service names on CentOS Stream. https://docs.openstack.org/neutron/xena/install/ describes installation method for various distros. Marking the bug as invalid, feel free to re open if wrong. ** 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/1957021 Title: openstack xena documenation has wrong neutron service name to start Status in neutron: Invalid Bug description: The manual install for neturon says to start - https://docs.openstack.org/neutron/xena/install/controller-install-obs.html# # systemctl enable openstack-neutron.service \ openstack-neutron-linuxbridge-agent.service \ openstack-neutron-dhcp-agent.service \ openstack-neutron-metadata-agent.service # systemctl start openstack-neutron.service \ openstack-neutron-linuxbridge-agent.service \ openstack-neutron-dhcp-agent.service \ openstack-neutron-metadata-agent.service But Xena neutron on centOS stream installs as [root@controller neutron]# cd /usr/lib/systemd/system [root@controller system]# ls -ltra neutron* -rw-r--r--. 1 root root 569 Oct 6 16:45 neutron-server.service -rw-r--r--. 1 root root 1024 Oct 6 16:45 neutron-ovs-cleanup.service -rw-r--r--. 1 root root 734 Oct 6 16:45 neutron-openvswitch-agent.service -rw-r--r--. 1 root root 987 Oct 6 16:45 neutron-netns-cleanup.service -rw-r--r--. 1 root root 536 Oct 6 16:45 neutron-metadata-agent.service -rw-r--r--. 1 root root 1039 Oct 6 16:45 neutron-linuxbridge-cleanup.service -rw-r--r--. 1 root root 645 Oct 6 16:45 neutron-linuxbridge-agent.service -rw-r--r--. 1 root root 512 Oct 6 16:45 neutron-l3-agent.service -rw-r--r--. 1 root root 516 Oct 6 16:45 neutron-dhcp-agent.service -rw-r--r--. 1 root root 579 Oct 6 16:50 neutron-destroy-patch-ports.service so the document has to be updated with the proper services to start. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1957021/+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
