May 2021 - openstack-discuss - lists.openstack.org

[stein][neutron] gratuitous arp
by Ignazio Cassano 13 May '21

13 May '21

Hello, I have a problem on stein neutron. When a vm migrate from one node to another I cannot ping it for several minutes. If in the vm I put a script that ping the gateway continously, the live migration works fine and I can ping it. Why this happens ? I read something about gratuitous arp. Please, help me ? Any workaround , please ? Best Regards Ignazio

3 33

Train upgrade from centos 7 to centos 8
by Ignazio Cassano 13 May '21

13 May '21

Hello Guys, anyone have tried to upgrade a train based on centos 7 to centos 8 without reinstalling ? Thks Ignazio

1 0

[octavia] victoria - loadbalancer works but its operational status is offline
by apps＠mossakowski.ch 13 May '21

13 May '21

Hello, I have stable/victoria baremetal openstack with octavia installed on centos8 using openvswitch mechanism driver: octavia api on controller, health-manager,housekeeping,worker on 3 compute/network nodes. Official docs include only ubuntu with linuxbridge mechanism but I used https://github.com/prastamaha/openstack-octavia as a reference to get it working on centos8 with ovs. I will push those docs instructions for centos8 soon: https://github.com/openstack/octavia/tree/master/doc/source/install. I created basic http scenario using https://docs.openstack.org/octavia/victoria/user/guides/basic-cookbook.html…. Loadbalancer works but its operational status is offline (openstack_loadbalancer_outputs.txt). On all octavia workers I see the same warning message in health_manager.log: Health Manager experienced an exception processing a heartbeat message from ('172.31.255.233', 1907). Ignoring this packet. Exception: 'NoneType' object has no attribute 'encode' I've searched for related active bug but all I found is this not related in my opinion: https://storyboard.openstack.org/#!/story/2008615 I'm attaching all info I've gathered: - octavia.conf and health_manager debug logs (octavia_config_and_health_manager_logs.txt) - tcpdump from amphora VM (tcpdump_from_amphora_vm.txt) - tcpdump from octavia worker (tcpdump_from_octavia_worker.txt) - debug amphora-agent.log from amphora VM (amphora-agent.log) Can you point me to the right direction what I have missed? Thanks! Piotr Mossakowski https://github.com/moss2k13

4 5

[openstack-helm] Announcing new core reviewers
by Gage Hugo 13 May '21

13 May '21

This week we announced the addition of Sangeet Gupta and Jinyuan Liu to the openstack-helm core reviewer team. Thanks to you both for your hard work!

1 0

[cinder] two priority reviews
by Brian Rosmaita 13 May '21

13 May '21

Hello Cinder team, Please direct your attention to these patches, which address issues that are preventing OpenStack from upgrading to SQLAlchemy 1.4 [0]: - https://review.opendev.org/c/openstack/cinder/+/790796 - https://review.opendev.org/c/openstack/cinder/+/790797 Thanks! [0] https://review.opendev.org/c/openstack/requirements/+/788339/

1 0

[CINDER] - RBD backend reporting
by Steven Relf 13 May '21

13 May '21

Hey list. Currently when using an RBD backend using the default settings, total_capacity_gb is reported as MAX_AVAIL + USED bytes, converted into GiB. This to mean seems a little odd, as I would expect that total_capacity_gb should report the total size in GiB of the backend cluster. This of course can be fixed by adding "report_dynamic_total_capacity = false" into the cinder.conf section for the rbd backend. This works fine for ceph clusters where all pools consume from a single disk type/root. But in clusters where you have multiple root's or device types it does not work correctly. Is this proving to be a pain point for anyone else, or is it just me, and if it is proving a problem for others, im happy to write a patch. Im thinking something that gets the pools crushrule and works out the total_capacity_gb, based off the total available capacity of a pool based on its root/crushrules. Rgds Steve. The future has already arrived. It's just not evenly distributed yet - William Gibson

2 1

[neutron] Drivers meeting 14.05.2021 cancelled
by Slawek Kaplonski 13 May '21

13 May '21

Hi, Due to lack of the agenda let's cancel tomorrow's drivers meeting. In the meantime, please review already accepted specs, especially those with review priority which can be found on: https://review.opendev.org/q/label:Review-priority%253D%252B1+project:opens… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/label:Review-priority%253D%252B1+project:opens…

1 0

[all][tc] Technical Committee next weekly meeting on May 13th at 1500 UTC
by Ghanshyam Mann 12 May '21

12 May '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for May 13th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, May 12th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[baremetal-sig][ironic] Tue May 11, 2021, 2pm UTC: Why Ironic?
by Arne Wiebalck 12 May '21

12 May '21

Dear all, The Bare Metal SIG will meet next week Tue May 11, 2021, at 2pm UTC on zoom. The meeting will feature a "topic-of-the-day" presentation by Arne Wiebalck (arne_wiebalck) on "Why Ironic? (The Case of Ironic in CERN IT)" As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome! Cheers, Arne

2 1

Wallaby RDO Release Announcement
by Amy Marrich 12 May '21

12 May '21

If you're having trouble with the formatting, this release announcement isavailable online at https://blogs.rdoproject.org/2021/05/rdo-wallaby-released/ --- *RDO Wallaby Released* The RDO community is pleased to announce the general availability of the RDO build for OpenStack Wallaby for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Wallaby is the 23rd release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8 <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> -stream <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> /cloud/x86_64/openstack- <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> wallaby <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/>/ <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/>. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: RDO Wallaby provides packages for CentOS Stream 8 and Python 3 only. Please use the Victoria release for CentOS8. For CentOS7 and python 2.7, please use the Train release. *Interesting things in the Wallaby release include:* - RBAC supported added in multiple projects including Designate, Glance, Horizon, Ironic, and Octavia - Glance added support for distributed image import - Ironic added deployment and cleaning enhancements including UEFI Partition Image handling, NVMe Secure Erase, per-instance deployment driver interface overrides, deploy time “deploy_steps”, and file injection. - Kuryr added nested mode with node VMs running in multiple subnets is now available. To use that functionality a new option [pod_vif_nested]worker_nodes_subnets is introduced accepting multiple Subnet IDs. - Manila added the ability for Operators to now set maximum and minimum share sizes as extra specifications on share types. - Neutron added a new subnet type network:routed is now available. IPs of this subnet type can be advertised with BGP over a provider network. - TripleO moved network and network port creation out of the Heat stack and into the baremetal provisioning workflow. Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/wallaby/highlights.html *Contributors* - During the Wallaby cycle, we saw the following new RDO contributors: - Adriano Petrich - Ananya Banerjee - Artom Lifshitz - Attila Fazekas - Brian Haley - David J Peacock - Jason Joyce - Jeremy Freudberg - Jiri Podivin - Martin Kopec - Waleed Mousa Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 58 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Adriano Petrich - Alex Schultz - Alfredo Moralejo - Amol Kahat - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Arx Cruz - Attila Fazekas - Bhagyashri Shewale - Brian Haley - Cédric Jeanneret - Chandan Kumar - Daniel Pawlik - David J Peacock - Dmitry Tantsur - Emilien Macchi - Eric Harney - Fabien Boucher - frenzyfriday - Gabriele Cerami - Gael Chamoulaud - Grzegorz Grasza - Harald Jensas - Jason Joyce - Javier Pena - Jeremy Freudberg - Jiri Podivin - Joel Capitao - Kevin Carter - Luigi Toscano - Marc Dequenes - Marios Andreou - Martin Kopec - Mathieu Bultel - Matthias Runge - Mike Turek - Nicolas Hicher - Pete Zaitcev - Pooja Jadhav - Rabi Mishra - Riccardo Pittau - Roman Gorshunov - Ronelle Landy - Sagi Shnaidman - Sandeep Yadav - Slawek Kaplonski - Sorin Sbarnea - Steve Baker - Takashi Kajinami - Tristan Cacqueray - Waleed Mousa - Wes Hayutin - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Xena. *Get Started* There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use TripleO and you’ll be running a production cloud in short order. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on Freenode IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0