[Yahoo-eng-team] [Bug 1982287] [NEW] [ovn] Support address group for ovn driver
Public bug reported: As the title describes, we can use 'address set' of ovn to support the feature that address group. ** Affects: neutron Importance: Undecided Assignee: Liu Xie (liushy) Status: New ** Changed in: neutron Assignee: (unassigned) => Liu Xie (liushy) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1982287 Title: [ovn] Support address group for ovn driver Status in neutron: New Bug description: As the title describes, we can use 'address set' of ovn to support the feature that address group. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1982287/+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 1982284] [NEW] libvirt live migration sometimes fails with "libvirt.libvirtError: internal error: migration was active, but no RAM info was set"
Public bug reported: We have seen this downstream where live migration randomly fails with the following error [1]: libvirt.libvirtError: internal error: migration was active, but no RAM info was set Discussion on [1] gravitated toward a possible race condition issue in qemu around the query-migrate command [2]. The query-migrate command is used (indirectly) by the libvirt driver during monitoring of live migrations [3][4][5]. While searching for info about this error, I found a thread on libvir- list from the past [6] where someone else encountered the same error and for them it happened if they called query-migrate *after* a live migration had completed. Based on this, it seemed possible that our live migration monitoring thread sometimes races and calls jobStats() after the migration has completed, resulting in this error being raised and the migration being considered failed when it was actually complete. A patch has since been proposed and committed [7] to address the possible issue. Meanwhile, on our side in nova, we can mitigate this problematic behavior by catching the specific error from libvirt and ignoring it so that a live migration in this situation will be considered completed by the libvirt driver. Doing this would improve the experience for users that are hitting this error and getting erroneous live migration failures. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2074205 [2] https://qemu.readthedocs.io/en/latest/interop/qemu-qmp-ref.html#qapidoc-1848 [3] https://github.com/openstack/nova/blob/bcb96f362ab12e297f125daa5189fb66345b4976/nova/virt/libvirt/driver.py#L10123 [4] https://github.com/openstack/nova/blob/bcb96f362ab12e297f125daa5189fb66345b4976/nova/virt/libvirt/guest.py#L655 [5] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetJobStats [6] https://listman.redhat.com/archives/libvir-list/2021-January/213631.html [7] https://github.com/qemu/qemu/commit/552de79bfdd5e9e53847eb3c6d6e4cd898a4370e ** Affects: nova Importance: Undecided Assignee: melanie witt (melwitt) Status: In Progress ** Tags: libvirt live-migration -- 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/1982284 Title: libvirt live migration sometimes fails with "libvirt.libvirtError: internal error: migration was active, but no RAM info was set" Status in OpenStack Compute (nova): In Progress Bug description: We have seen this downstream where live migration randomly fails with the following error [1]: libvirt.libvirtError: internal error: migration was active, but no RAM info was set Discussion on [1] gravitated toward a possible race condition issue in qemu around the query-migrate command [2]. The query-migrate command is used (indirectly) by the libvirt driver during monitoring of live migrations [3][4][5]. While searching for info about this error, I found a thread on libvir- list from the past [6] where someone else encountered the same error and for them it happened if they called query-migrate *after* a live migration had completed. Based on this, it seemed possible that our live migration monitoring thread sometimes races and calls jobStats() after the migration has completed, resulting in this error being raised and the migration being considered failed when it was actually complete. A patch has since been proposed and committed [7] to address the possible issue. Meanwhile, on our side in nova, we can mitigate this problematic behavior by catching the specific error from libvirt and ignoring it so that a live migration in this situation will be considered completed by the libvirt driver. Doing this would improve the experience for users that are hitting this error and getting erroneous live migration failures. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2074205 [2] https://qemu.readthedocs.io/en/latest/interop/qemu-qmp-ref.html#qapidoc-1848 [3] https://github.com/openstack/nova/blob/bcb96f362ab12e297f125daa5189fb66345b4976/nova/virt/libvirt/driver.py#L10123 [4] https://github.com/openstack/nova/blob/bcb96f362ab12e297f125daa5189fb66345b4976/nova/virt/libvirt/guest.py#L655 [5] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetJobStats [6] https://listman.redhat.com/archives/libvir-list/2021-January/213631.html [7] https://github.com/qemu/qemu/commit/552de79bfdd5e9e53847eb3c6d6e4cd898a4370e To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1982284/+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 1449639] Re: RBD: On image creation error, image is not deleted
** Changed in: glance-store/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1449639 Title: RBD: On image creation error, image is not deleted Status in Glance: Fix Released Status in Glance icehouse series: Fix Released Status in glance_store: Fix Released Status in glance_store kilo series: Fix Released Bug description: When an exception rises while adding/creating an image, and the image has been created, this new image is not properly deleted. The fault lies in the `_delete_image` call of the Store.add method that is providing incorrect arguments. This also affects Glance (Icehouse), since back then glance_store functionality was included there. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1449639/+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 1981646] Re: network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords
Alternative solution to this could be if netplan.io grows a new root- only directory option that defines a schema for storing sensitive information like credentials. Not sure if this is something netplan.io would plan to grow or not. Tagging netplan.io on this bug as an FYI `wishlist` in case future feature work goes this direction. The features that may be nice from netplan frm a usability standpoint: 1. documented policy that suggests chmod 600 on any netplan YAML 2. Instrumented policy in `netplan generate` or `netplan apply` that warns about world-readable files consumed which happen to contain security-related keys. 3. Ideally, sensitive YAML content root-only files wouldn't live in with world-readable content in /etc/netplan/* files. Possibly define a sensitive/security/credentials subdirectory/schema that could contain the security bits. This is probably not the bug to file against netplan.io as it contains multiple feature request, but I wanted to track the sentiment in case that effort is becomes something desireable for netplan (and thereby affecting how cloud-init should write out sensitive files). ** Also affects: netplan Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1981646 Title: network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords Status in cloud-init: Triaged Status in netplan: New Bug description: https://netplan.io/reference/ supports wifi password and auto client- key-password keys which should generally not be world-readable. But, when rendering passthrough V2 network configuration, cloud-init emits a single /etc/netplan/50-cloud-init.yaml file that is world readable. If network v2 config contains sensitive password keys it may make sense for cloud-init to either: 1. Make /etc/netplan/50-cloud-init.yaml only root-readable - OR - 2. Write a world-readable /etc/netplan/50-cloud-init.yaml containing all keys except wifis and auth and a root-readable /etc/netplan/50-cloud-init-sensitive.yaml which would contain any security sensitive config content. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1981646/+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 1982206] [NEW] stable: Neutron unit tests timeout on stable/ussuri and stable/victoria (perhaps wallaby also)
Public bug reported:
On stable branches the unit tests fail with time out on Ussuri and
Victoria branches (on Wallaby there's also a timeout but it has
different log, so perhaps just an accident, see [3])
The periodic jobs show the issue and my test patch also (see [1] and
[2])
The timeout happens with this pattern, always after the test
test_two_member_trailing_chain:
2022-07-19 02:48:57.591352 | ubuntu-focal | {1}
neutron.tests.unit.test_wsgi.TestWSGIServer.test_disable_ssl [0.039549s] ... ok
2022-07-19 02:48:57.613094 | ubuntu-focal | {1}
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_two_member_trailing_chain
[0.021062s] ... ok
2022-07-19 03:05:57.910628 | RUN END RESULT_TIMED_OUT: [untrusted :
opendev.org/zuul/zuul-jobs/playbooks/tox/run.yaml@master]
2022-07-19 03:05:57.926082 | POST-RUN START: [untrusted :
opendev.org/zuul/zuul-jobs/playbooks/tox/post.yaml@master]
[1]:
https://lists.openstack.org/pipermail/openstack-stable-maint/2022-July/094216.html
[2]:
https://72340191a2149eb73d49-2d27e805ff456f7d0a585c8eee091a7d.ssl.cf2.rackcdn.com/850391/1/check/openstack-tox-py37/9ab5c3a/job-output.txt
[3]:
https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f2a/periodic-stable/opendev.org/openstack/neutron/stable/wallaby/openstack-tox-py38/f2a3976/job-output.txt
** Affects: neutron
Importance: Critical
Status: New
** Tags: gate-failure
** 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/1982206
Title:
stable: Neutron unit tests timeout on stable/ussuri and
stable/victoria (perhaps wallaby also)
Status in neutron:
New
Bug description:
On stable branches the unit tests fail with time out on Ussuri and
Victoria branches (on Wallaby there's also a timeout but it has
different log, so perhaps just an accident, see [3])
The periodic jobs show the issue and my test patch also (see [1] and
[2])
The timeout happens with this pattern, always after the test
test_two_member_trailing_chain:
2022-07-19 02:48:57.591352 | ubuntu-focal | {1}
neutron.tests.unit.test_wsgi.TestWSGIServer.test_disable_ssl [0.039549s] ... ok
2022-07-19 02:48:57.613094 | ubuntu-focal | {1}
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_two_member_trailing_chain
[0.021062s] ... ok
2022-07-19 03:05:57.910628 | RUN END RESULT_TIMED_OUT: [untrusted :
opendev.org/zuul/zuul-jobs/playbooks/tox/run.yaml@master]
2022-07-19 03:05:57.926082 | POST-RUN START: [untrusted :
opendev.org/zuul/zuul-jobs/playbooks/tox/post.yaml@master]
[1]:
https://lists.openstack.org/pipermail/openstack-stable-maint/2022-July/094216.html
[2]:
https://72340191a2149eb73d49-2d27e805ff456f7d0a585c8eee091a7d.ssl.cf2.rackcdn.com/850391/1/check/openstack-tox-py37/9ab5c3a/job-output.txt
[3]:
https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f2a/periodic-stable/opendev.org/openstack/neutron/stable/wallaby/openstack-tox-py38/f2a3976/job-output.txt
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1982206/+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 1982111] [NEW] [ovn-octavia-provider] members without subnet wrongly associated to VIP subnet
Public bug reported: When members are added without subnet_id information, the ovn-octavia provider used the VIP subnet for the subnet_id. However, if the member does not belong to the same subnet as the VIP subnet (i.e., different cidr), the API does not return any error but there is no connectivity to the member (as it does not belong to the obtained subnet). An extra checking to ensure the VIP CIDR includes the member IP should be done. ** Affects: neutron Importance: Undecided Assignee: Luis Tomas Bolivar (ltomasbo) 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/1982111 Title: [ovn-octavia-provider] members without subnet wrongly associated to VIP subnet Status in neutron: In Progress Bug description: When members are added without subnet_id information, the ovn-octavia provider used the VIP subnet for the subnet_id. However, if the member does not belong to the same subnet as the VIP subnet (i.e., different cidr), the API does not return any error but there is no connectivity to the member (as it does not belong to the obtained subnet). An extra checking to ensure the VIP CIDR includes the member IP should be done. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1982111/+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 1982110] [NEW] [taap-as-a-service] Project requires "webtest" library for testing
Public bug reported: Project: taap-as-a-service According to logs [1], "webtest" library is required for testing but not installed [2]. [1]https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_8aa/698035/12/check/openstack-tox-py38/8aa43cd/job-output.txt [2]https://paste.opendev.org/show/bFDIyynkXdMAnVPtJJ7K/ ** 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/1982110 Title: [taap-as-a-service] Project requires "webtest" library for testing Status in neutron: New Bug description: Project: taap-as-a-service According to logs [1], "webtest" library is required for testing but not installed [2]. [1]https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_8aa/698035/12/check/openstack-tox-py38/8aa43cd/job-output.txt [2]https://paste.opendev.org/show/bFDIyynkXdMAnVPtJJ7K/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1982110/+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
