September 2022 - openstack-discuss

[neutron] Bug deputy report for week of August 29th
by Brian Haley 06 Sep '22

06 Sep '22

Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. BTW, you don't have to wait for me to be deputy to file all your bugs :) -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1988026 - Neutron should not create security group with project==None - Talked to Security Response Team and they decided to add a tracker to it since the quota system doesn't seem to limit how many random default security groups one can create. - https://review.opendev.org/c/openstack/neutron/+/855580 High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1988037 - Neutron does not find an existing route - https://review.opendev.org/c/openstack/neutron/+/854986 * https://bugs.launchpad.net/neutron/+bug/1988296 - neutron-lib pep8 CI failing with pylint==2.15.0 - https://review.opendev.org/c/openstack/neutron-lib/+/855061 Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1988069 - neutron-dhcp-agent fails when small tenant network mtu is set - Could not reproduce issue reported with MTU as 70 for network, only saw that instances could not do DHCP with it so small. Looks like a potential kernel bug since this works on later versions. * https://bugs.launchpad.net/neutron/+bug/1988199 - https://review.opendev.org/c/openstack/neutron/+/855257 * https://bugs.launchpad.net/neutron/+bug/1988220 - large unused dependency ncclient + paramiko in os-ken - Assigned to Rodolfo since he made change to remove nose https://review.opendev.org/c/openstack/os-ken/+/850631 - closed (won't-fix) as ncclient is required for os-ken, just wasn't explicitly called-out in requirements. * https://bugs.launchpad.net/neutron/+bug/1988549 - Trunk status is down after a live-migration - Arnau Verdaguer took ownership Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1988298 - [neutron-lib] "registry.has_resource_extenders" is the same as "resource_extend.has_resource_extenders" - Needs owner * https://bugs.launchpad.net/neutron/+bug/1586731 - restart neutron ovs agent will leave the fanout queue behind - Old bug re-opened - Partial patch posted, asked commenter to submit to master Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/1988281 - neutron dhcp agent state not consistent with real status - After a restart, the agent status is UP even though it is still doing a full-sync operation, is there a way to signify this status? See bug for further discussion. * https://bugs.launchpad.net/neutron/+bug/1988382 - L3 agent(agent_mode=dvr_snat) restart, fip namespace removed rfp-port, resulting in fip not connecting - Failure is seen in code from 2019, asked submitter to try tip of stable/victoria and reproduce since there have been fixed in this area since then. Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1988077 - Noisy neutron-openvswitch-agent service - There are some deployments that wanted more logging which is why the agent is more verbose. Will have to have a further discussion to see if there is a way to address concern of log being noisy, besides using more aggressive log rotation as suggested. * https://bugs.launchpad.net/neutron/+bug/1988188 - Create an automated tool to retrieve the needed OVS version depending on the OVN one - Suggested by Rodolfo to help improve gate dependencies. * https://bugs.launchpad.net/neutron/+bug/1988542 - [RFE] OVN support for vnic type virtio-forwarder - Will need to add to Drivers meeting agenda

1 0

Two containers fail
by Derek O keeffe 06 Sep '22

06 Sep '22

Hi, I recently successfully installed OSA and I am now trying to install it again from scratch with all the configuration changes I needed in place. Unfortunately this time around it is failing on setup_hosts.yml here: TASK [lxc_container_create : Create container (dir)] ******************************************************************ok: [infra1_memcached_container-b92f4db7 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_rabbit_mq_container-d286a482 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_utility_container-05f756fc -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_galera_container-5beef059 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_aodh_container-639f5ad8 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_neutron_server_container-f67e972d -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_horizon_container-dfeaa0dc -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_placement_container-350e4ede -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_heat_api_container-82cbd764 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_nova_api_container-b30c38d1 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_repo_container-f16e50a9 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_ceilometer_central_container-910a888f -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_keystone_container-32dcd68b -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_gnocchi_container-30ccb451 -> infra1(CONTROLLER_IP_ADDRESS)]fatal: [infra1_cinder_api_container-840a18bb -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_cinder_api_container-840a18bb ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_cinder_api_container-840a18bb", "state": "stopped"}, "msg": "The container [ infra1_cinder_api_container-840a18bb ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1}fatal: [infra1_glance_container-b50e16a6 -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_glance_container-b50e16a6 ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_glance_container-b50e16a6", "state": "stopped"}, "msg": "The container [ infra1_glance_container-b50e16a6 ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} I don't understand how 14 containers are fine (can be attached to and commands run through lxc-attach) and 2 containers are failing. I have a deploy host, controller and two computes all with a fresh install of Ubuntu 20.04. The bootstrap_ansible script ran fine on the deploy host and the setup_hosts playbook ran through fully as after the above it skipped cinder and glance containers every where else. Can anybody please point me in the direction of getting more info or a possible cause. Thanks in advance.

2 2

[Octavia][release] Requesting exception for python-octaviaclient
by Gregory Thiemonge 06 Sep '22

06 Sep '22

Hi Folks, I am requesting a Feature Freeze Exception for the release of python-octaviaclient for Zed. One patch [0] was merged at the end of last week in python-octaviaclient (we were waiting for the related feature to get merged in the octavia repo) and a new release (3.1.0) was proposed for Zed in the release repo [1], but it wasn't merged in time. We would like to get the approval for this new release so we could base the stable/zed branch on this new tag (we would need to update [2]). Thanks, Gregory [0] https://review.opendev.org/c/openstack/python-octaviaclient/+/664473 [1] https://review.opendev.org/c/openstack/releases/+/855675 [2] https://review.opendev.org/c/openstack/releases/+/855912

2 1

[election][tripleo] PTL Candidacy for Antelope cycle
by Rabi Mishra 06 Sep '22

06 Sep '22

Hi All, I would like to nominate myself for Antelope cycle TripleO PTL. As some of you would know, I have been part of the OpenStack community for a long time and have been a core contributor for TripleO and Heat. I have also served as Heat PTL for Ocata cycle. James has done a great job as PTL for the last few cycles. I would like to take the opportunity to thank him for all his effort and we all would agree that he needs a well deserved break. I am looking forward to take the opportunity to help the community to achieve some of the already planned goals and in-progress workstreams like standalone roles, multi-rhel and other challenges that come along the way. Also, as before, our focus would continue to be on review prioritization, in progress work streams and collaboration on common priorities. Regards, Rabi Mishra

9 8

[nova]How to confirm whether a arm64 node supports hardware acceleration for virtual machines
by 韩光宇 06 Sep '22

06 Sep '22

Hello, I see `egrep -c '(vmx|svm)' /proc/cpuinfo` in nova install documentation[1]. It can be used to confirm whether a node supports hardware acceleration for virtual machines on x86 architecture. But it is not applicable in the ARM architecture. Do we have an officially recommended method to confirm in ARM architecture? Thanks, Han Guangyu [1]https://docs.openstack.org/nova/latest/install/compute-install-rdo.html#f…

3 2

[oslo][relmgmt][taskflow][nova] fasteners.ReaderWriterLock and oslo.concurrency's fair lock is broken if used in eventlet
by Balazs Gibizer 06 Sep '22

06 Sep '22

Hi, It is hard to properly figure out which OpenStack project is affected exactly. But I want to give a heads up. If the following is true for your project then you are affected: * using eventlet and * using oslo.concurrency fair internal lock (external lock or non fair locks are not affected) or using fasteners.ReaderWriterLock directly. I know that nova is affected and based on code search taskflow is affected at least. The oslo.concurrency's fair lock uses fasteners.ReaderWriterLock[1]. The fasteners.ReaderWriterLock relies on threading.current_thread to identify a thread and decide if a thread already has a lock and therefore can reenter the lock. However in an eventlet monkey patched environment, a thread that is created with eventlet.spawn_n() or the patched threading.Thread() the threading.current_thread call does not return an eventlet unique ID. This causes that the lock can be reentered from multiple eventlets at the same time. We have 4 ways forward: 0) Fix eventlet. There is an open issue in eventlet[3] for this open since October 2021. Based on the ticket this direction does not seems to feasible. 1) Sean recently opened an issue[4] on fasteners to restore a previously existing workaround that could fix our issues. If an new fasteners lib is released with the workaround[5] then at least oslo.concurrency requirements needs to be bumped and a new oslo release is pushed. 2) If the fasteners' maintainer does not accept [4][5] in time then I have an oslo.concurrency patch[6] that implements a workaround in oslo. This also requires a new olso.concurrency release. Also this means that projects that are using fasteners.ReaderWriterLock directly need to re-implement the fix locally. 3) If all odds fails I have a nova only patch[7] that implements the workaround locally in nova. Note that this issue is present in stable/yoga and on master. On stable/xena we uses fasteners < 0.15.0 which is not affected. Cheers, gibi [1] https://github.com/openstack/oslo.concurrency/blob/052b2f23572900601b0f4138… [2] https://bugs.launchpad.net/oslo.concurrency/+bug/1988311 [3] https://github.com/eventlet/eventlet/issues/731 [4] https://github.com/harlowja/fasteners/issues/96 [5] https://github.com/harlowja/fasteners/pull/97 [6] https://review.opendev.org/q/topic:bug/1988311+project:openstack/oslo.concu… [7] https://review.opendev.org/q/topic:bug/1988311+project:openstack/nova

2 2

[ops][largescale-sig] rabbitmq and the durability of reply_ queues
by Felix Hüttner 06 Sep '22

06 Sep '22

Hi everyone, the largescale-sig currently recommends the following rabbitmq policy [1]: '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. If I found the history of this setting correctly, it resulted from this mailinglist thread [2] which came to the conclusion: > * use durable-queue and replication for long-running queues/exchanges > * use non-durable-queue without replication for short (fanout, reply_) queues However I am unsure if reply_ queues are actually shorted lived than the "long-running" ones. If we take the example of the cinder-scheduler we have the following queues: * cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler cluster; currently durable + replicated * cinder-scheduler.myhostname: Tied to the lifetime of the cinder-scheduler service, but not removed when the service stops; currently durable + replicated * cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated * reply_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated If I read got all of the above correctly then reply_ and fanout queues are actually not shorter lived than the normal queue to send requests to that service. The only difference is that we remove them when the service itself stops. Therefor I want to propose the question if we should not also make these queues durable and replicated. Thank you [1]: https://docs.openstack.org/large-scale/other/rabbitmq.html#pattern [2]: https://lists.openstack.org/pipermail/openstack-discuss/2020-August/016562.… -- Felix Huettner Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.

2 2

[puppet] Gate blocker: enabling neutron-ovn-metadata-agent consistently fails in CentOS Stream 9
by Takashi Kajinami 06 Sep '22

06 Sep '22

Hello, Currently we are facing a problem with integration jobs with ml2+ovn in CentOS Stream 9 ( puppet-openstack-integration-7-scenario00[35]-tempest-centos-9-stream ) and these jobs are consistently failing. Details can be found in https://launchpad.net/bugs/1988552 . I've already reported the issue to RDO and CentOS Stream to get their help while I'm also implementing a temporary workaround. https://review.opendev.org/c/openstack/puppet-openstack-integration/+/855617 Please avoid rechecking/approving patches until these jobs are fixed. Thank you, Takashi

1 1

Re: Secret getPayload() openstack4j
by Srinivasan T 06 Sep '22

06 Sep '22

Hi, Does anyone have any idea on this? >From the REST API documentation, it seems GET /v1/secret/{uuid} may not fetch the payload and we need to use a different endpoint GET /v1/secret/{uuid}/payload . Is there any equivalent Java API (openstack4j) for this? Regards, Srini On Mon, Sep 5, 2022 at 11:08 PM Srinivasan T <tsrini.alr(a)gmail.com> wrote: > Thanks Artem for the response. > > I face the same issue when using the below version as well (snippet from > pom.xml), > > <modelVersion>4.0.0</modelVersion> > <artifactId>openstack4j-core</artifactId> > <name>OpenStack4j Core</name> > <description>OpenStack Java API</description> > <url>http://github.com/openstack4j/openstack4j/</url> > > Regards, > Srini > > On Mon, Sep 5, 2022 at 9:48 PM Artem Goncharov <artem.goncharov(a)gmail.com> > wrote: > >> Hi, >> >> The library is not an official OpenStack delivery. I guess nobody here >> would be able to give you proper suggestion. Moreover it does not look like >> being actively maintained. >> >> Regards, >> Artem >> >> On 5. Sep 2022, at 18:03, Srinivasan T <tsrini.alr(a)gmail.com> wrote: >> >> Hi, >> >> I'm unable to get the secret's payload from openstack4j, it always >> returns null. >> >> Secret secret = os.barbican().secrets().get("19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60"); >> secret.getPayload(); //Always returns null >> >> The same works when using the OpenStack CLI, >> >> openstack secret get --payload_content_type 'application/octet-stream' --file secret-payload http://x.x.x.x:9311/v1/secrets/19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60 >> >> I'm using the below OpenStack4j version, >> >> Bundle-Name: OpenStack4j Core >> >> Bundle-Version: 3.6.0 >> >> OpenStack is in Queens version. >> >> Let me know if someone can help on this. >> Regards, >> Srini >> >> >>

1 0

Kolla-ansible all-in-one and Hyper Converged solution
by KK CHN 06 Sep '22

06 Sep '22

Hi, [1 ] I am aiming for a prototype of HCI on a DELL ( R650 2 CPU and 40 cores . 2.4 TB) server machine. The Operating System choice is Debian 10. [2] Right now I am successful in Kolla-ansible all-in-one installation of Wallaby/stable on a Debian 10 Virtual machine with the default configs enabled as in the documentation " https://docs.openstack.org/project-deploy-guide/kolla-ansible/wallaby/uicks… " in Virtualenv setup. Able to get the horizon dashboard with the default services enabled and created and tested the cirros VM launching .. working fine. [3 ] I have to repeat the same all-in-one deployment on the physical machine as in [1] with the default configs and then convert it as an HCI node. What all features do I need to configure / enable in all-in-on / globals.yml to convert this box as a working HCI node ? Any hints / directives for the essential configurations needed for this server box to convert it as an HCI node are most welcome. kindly shed some light on this and any reference documents/URLs to do this ? Thank you, Krish

5 5