January 2022 - openstack-discuss - lists.openstack.org

[TripleO] Proposing Juan Badia Payno for TripleO core reviewer.
by Carlos Camacho Gonzalez 26 Jan '22

26 Jan '22

Hi everyone! I'd like to propose Juan Badia Paino [1][2][3] as a core reviewer on the TripleO repositories that are or might be related to the backup and restore efforts (openstack/tripleo-ci, openstack/tripleo-ansible, openstack/python-tripleoclient, openstack/tripleo-quickstart-extras, openstack/tripleo-quickstart). Juan has been around since 2016 making useful contributions and code reviews to the community and I believe adding him to our core reviewer group will help us improve the review and coding speed for the backup and restore codebase. As usual, consider this email as an initial +1 from my side, I will keep an eye on this thread for a week, and based on your feedback and if there are no objections I will add him as a core reviewer in two weeks. [1]: https://review.opendev.org/q/owner:jbadiapa%2540redhat.com [2]: https://www.stackalytics.io/?project_type=all&metric=commits&user_id=jbadia… [3]: https://www.stackalytics.io/report/contribution?module=tripleo-group&projec… Cheers, Carlos.

9 9

Re: Re: [ops] [kolla] RabbitMQ High Availability
by Albert Braden 25 Jan '22

25 Jan '22

Replying from my home email because I've been asked to not email the list from my work email anymore, until I get permission from upper management. I'm not sure I follow. I was planning to add 2 lines to etc/kolla/config/global.conf: [oslo_messaging_rabbit] amqp_durable_queues = False Is that not sufficient? What is involved in configuring dedicated control exchanges for each service? What would that look like in the config? From: Herve Beraud <hberaud(a)redhat.com> Sent: Thursday, December 9, 2021 2:45 AM To: Bogdan Dobrelya <bdobreli(a)redhat.com> Cc: openstack-discuss(a)lists.openstack.org Subject: [EXTERNAL] Re: [ops] [kolla] RabbitMQ High Availability Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Le mer. 8 déc. 2021 à 11:48, Bogdan Dobrelya <bdobreli(a)redhat.com> a écrit : Please see inline >> I read this with great interest because we are seeing this issue. Questions: >> >> 1. We are running kola-ansible Train, and our RMQ version is 3.7.23. Should we be upgrading our Train clusters to use 3.8.x? >> 2. Document [2] recommends policy '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. I don't see this in our ansible playbooks, nor in any of the config files in the RMQ container. What would this look like in Ansible, and what should the resulting container config look like? >> 3. It appears that we are not setting "amqp_durable_queues = True". What does this setting look like in Ansible, and what file does it go into? > > Note that even having rabbit HA policies adjusted like that and its HA > replication factor [0] decreased (e.g. to a 2), there still might be > high churn caused by a large enough number of replicated durable RPC > topic queues. And that might cripple the cloud down with the incurred > I/O overhead because a durable queue requires all messages in it to be > persisted to a disk (for all the messaging cluster replicas) before they > are ack'ed by the broker. > > Given that said, Oslo messaging would likely require a more granular > control for topic exchanges and the durable queues flag - to tell it to > declare as durable only the most critical paths of a service. A single > config setting and a single control exchange per a service might be not > enough. Also note that therefore, amqp_durable_queue=True requires dedicated control exchanges configured for each service. Those that use 'openstack' as a default cannot turn the feature ON. Changing it to a service specific might also cause upgrade impact, as described in the topic [3]. The same is true for `amqp_auto_delete=True`. That requires dedicated control exchanges else it won't work if each service defines its own policy on a shared control exchange (e.g `openstack`) and if policies differ from each other. [3] https://review.opendev.org/q/topic:scope-config-opts > > There are also race conditions with durable queues enabled, like [1]. A > solution could be where each service declare its own dedicated control > exchange with its own configuration. > > Finally, openstack components should add perhaps a *.next CI job to test > it with durable queues, like [2] > > [0] https://www.rabbitmq.com/ha.html#replication-factor > > [1] > https://zuul.opendev.org/t/openstack/build/aa514dd788f34cc1be3800e6d7dba0e8… > > [2] https://review.opendev.org/c/openstack/nova/+/820523 > >> >> Does anyone have a sample set of RMQ config files that they can share? >> >> It looks like my Outlook has ruined the link; reposting: >> [2] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando -- Best regards, Bogdan Dobrelya, Irc #bogdando -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

6 16

Compute Node Not Getting PXE boot During Scale-In/Out Activity
by Pradeep Antil 25 Jan '22

25 Jan '22

Hello Folks, Hope you are doing well ! I have a compute node (SRIOV) in my RedHat Openstack 13 Lab. I have a task to remove the sriov compute and add it back as a dpdk compute node. After removing this node as scale-in activity via overcloud stack when I tried to add it again, introspection for this node is failing. After looking into the logs in undercloud , it appears like it is not getting the ip address from pxe. # cat /var/log/messages|grep -i "0c:42:a1:45:03:10" --color [image: image.png] [root@director ~]# tcpdump -n -i br-ctlplane -e | grep -i "0c:42:a1:45:03:10" --color tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br-ctlplane, link-type EN10MB (Ethernet), capture size 262144 bytes 23:54:08.653057 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 436: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 394 23:54:12.669877 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 436: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 394 23:54:20.744605 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 436: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 394 23:54:36.839226 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 436: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 394 23:56:48.967623 0c:42:a1:45:03:10 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:56:49.044752 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 23:56:49.269645 0c:42:a1:45:03:10 > 33:33:ff:45:03:10, ethertype IPv6 (0x86dd), length 86: :: > ff02::1:ff45:310: ICMP6, neighbor solicitation, who has fe80::e42:a1ff:fe45:310, length 32 23:56:49.781577 0c:42:a1:45:03:10 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:56:50.271663 0c:42:a1:45:03:10 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::e42:a1ff:fe45:310 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:56:50.271922 0c:42:a1:45:03:10 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::e42:a1ff:fe45:310 > ff02::2: ICMP6, router solicitation, length 16 23:56:50.368576 0c:42:a1:45:03:10 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::e42:a1ff:fe45:310 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:56:54.274049 0c:42:a1:45:03:10 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::e42:a1ff:fe45:310 > ff02::2: ICMP6, router solicitation, length 16 23:56:54.675024 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 23:56:58.282332 0c:42:a1:45:03:10 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::e42:a1ff:fe45:310 > ff02::2: ICMP6, router solicitation, length 16 23:57:07.638252 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 23:57:10.053205 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 23:57:18.720085 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 23:57:32.817306 0c:42:a1:45:03:10 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0c:42:a1:45:03:10, length 300 Physical connectivity of this node is intact. Any idea and suggestions ? how this issue can be fixed. -- Best Regards Pradeep Kumar

1 0

[neutron] Bug Deputy Report Jan 17 - 23
by Oleg Bondarev 25 Jan '22

25 Jan '22

Hi everyone, Please find Bug Deputy report for the week Jan 17 - 23rd below. 1 Critical bug (with a related logs-improving patch from Slawek) looks for volunteers. A couple of Medium bugs: an l3-bgp bug to be verified by bgp team - 1958627, and an ipv6+ovs firewall bug - 1958643. Also several OVN bug needs some triage from OVN folks + assignees. Details: Critical -------- - https://bugs.launchpad.net/neutron/+bug/1958363 - Notifications to nova disabled causing tests failures - Confirmed - Related patch: https://review.opendev.org/c/openstack/neutron/+/825513 - Unassigned! Medium ---------- - https://bugs.launchpad.net/neutron/+bug/1958627 - Incomplete ARP entries on L3 gw namespace - Opinion - Unassigned! - https://bugs.launchpad.net/neutron/+bug/1958149 - ha backup router ipv6 accept_ra broken - In progress: https://review.opendev.org/c/openstack/neutron/+/824947 - Assigned to Maximilian Stinsky - https://bugs.launchpad.net/neutron/+bug/1958364 - [ovn]Set NB/SB connection inactivity_probe does not work for cluster - In progress: https://review.opendev.org/c/openstack/neutron/+/825269 - Assigned to ZhouHeng - https://bugs.launchpad.net/neutron/+bug/1958225 - [ovn]chassis available zone changed, not reschedule router gateway_chassis - In progress: https://review.opendev.org/c/openstack/neutron/+/825073 - Assigned to ZhouHeng - https://bugs.launchpad.net/neutron/+bug/1958353 - [ovn]Gateway port is down after gateway chassis changed - In progress: https://review.opendev.org/c/openstack/neutron/+/825041 - Assigned to ZhouHeng - https://bugs.launchpad.net/neutron/+bug/1958501 - [ovn]Refusing to bind port to dead agent - In progress: https://review.opendev.org/c/openstack/neutron/+/825428 - Assigned to ZhouHeng - https://bugs.launchpad.net/neutron/+bug/1958643 - Unicast RA messages for a VM are filtered out by ovs rules - Confirmed - Unassigned! Low ----- - https://bugs.launchpad.net/neutron/+bug/1958513 - [test]The unit test file ovn_l3.test_plugin cannot be run alone - In progress: https://review.opendev.org/c/openstack/neutron/+/825478 - Assigned to ZhouHeng Undecided ------------- - https://bugs.launchpad.net/neutron/+bug/1958355 - Undecided - Unassigned! - https://bugs.launchpad.net/neutron/+bug/1958561 - [ovn-octavia-provider] Listner/Pool Stuck in PENDING_CREATE Using Fully Populated LB API - Undecided - Unassigned! - https://bugs.launchpad.net/neutron/+bug/1958593 - [ovn]neutron-server allow more efficient reconnections when connecting to clustered OVSDB servers - Undecided - Unassigned! Invalid -------- - https://bugs.launchpad.net/neutron/+bug/1958128 - Neutron l3 agent keeps restarting (Ubuntu) Expired --------- - https://bugs.launchpad.net/neutron/+bug/1939680 - Neutron - set "dns_domain" for existing network is passively failing when Designate DNS extension is not enabled for Neutron - Undecided - Unassigned Thanks, Oleg --- Advanced Software Technology Lab Huawei

1 0

[Oslo] First IRC meeting of the year.
by Daniel Mats Niklas Bengtsson 25 Jan '22

25 Jan '22

Hi there, Yesterday we had the first oslo IRC meeting. You can find the log[1] on the meeting. Sorry I forget the ping and I confused the hour, but I will do better job next time. [1] https://meetings.opendev.org/meetings/oslo/2022/

1 0

Openstack+Magnum for edge
by Vikarna Tathe 25 Jan '22

25 Jan '22

Hello All, Is there a solution available for OpenStack controllers at a central location and computes at the edge (far from central)? If not what's the alternative? Any help would be appreciated. Thanks, Vikarna

1 0

[openstack-helm] No meeting tomorrow
by Gage Hugo 25 Jan '22

25 Jan '22

Hey team, Since there's nothing on the agenda for tomorrow's meeting, it has been cancelled. We will meet again next week.

1 0

答复: [cyborg] Proposing core reviewers
by Brin Zhang(张百林) 25 Jan '22

25 Jan '22

> ��: Brin Zhang(�Ű��) > ��ʱ��: 2022��1��17�� 9:13 > �ռ��: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> > ��: 'xin-ran.wang(a)intel.com' <xin-ran.wang(a)intel.com>; Alex Song (��ƽ) <songwenping(a)inspur.com>; 'huangzhipeng(a)huawei.com' <huangzhipeng(a)huawei.com>; 'liliueecg(a)gmail.com' <liliueecg(a)gmail.com>; 'shogo.saito.ac(a)hco.ntt.co.jp' <shogo.saito.ac(a)hco.ntt.co.jp>; 'sundar.nadathur(a)intel.com' <sundar.nadathur(a)intel.com>; 'yumeng_bao(a)yahoo.com' <yumeng_bao(a)yahoo.com>; 'chen.ke14(a)zte.com.cn' <chen.ke14(a)zte.com.cn>; '419546439(a)qq.com' <419546439(a)qq.com>; 'shaohe.feng(a)intel.com' <shaohe.feng(a)intel.com>; 'wangzhengh(a)chinatelecom.cn' <wangzhengh(a)chinatelecom.cn>; 'zhuli2317(a)gmail.com' <zhuli2317(a)gmail.com> >��: [cyborg] Proposing core reviewers > Hello all, > Eric xie has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches. Despite the relatively short time, he has been one of the most prolific contributors, > and brings an enthusiastic and active mindset. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg. fwiw, saw no negative votes, so added Eric to cyborg-core group. Welcome Eric on board and thanks for helping the community ! > Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months > �C i.e. no participation in meetings, no code contributions, not participating in Cyborg open source activities and no reviews �C be removed from the list of core reviewers. > -- The Cyborg team recognizes everyone's contributions, but we need to ensure the activity of the core-reviewer list. If you are interested in rejoining the cyborg team, feel free to ping us to restore the core reviewer for you. > If no objections are made known by January 24, I will make the changes proposed above.. > Regards, > Brin Zhang

1 0

[PTG] April 2022 Virtual PTG Dates & Registration
by Kendall Nelson 24 Jan '22

24 Jan '22

Hello Everyone! We're happy to announce the next virtual PTG[1] will take place April 4-8, 2022! Registration is now open[2]. The virtual PTG is free to attend, but make sure to register so you receive important communications like schedules, passwords, and other relevant updates. Next week, keep an eye out for info regarding team sign-ups. Can't wait to see you all there! -Kendall (diablo_rojo) [1] https://www.openstack.org/ptg/ [2] https://openinfra-ptg.eventbrite.com/

1 0

[sdk] R1 branch merged into master
by Artem Goncharov 24 Jan '22

24 Jan '22

Hi everybody, Just wanted to give a hint that feature/r1 branch of the OpenStackSDK is now merged into the master. While most of the challenging things are now completed the work is not finished yet, but will soon be. Most important: most of the work is backward compatible, but few things were not. I took care on keeping things working and testing, but there might be side effects that I have not expected. Please let me know if jobs in your projects start failing. Regards, Artem

2 2