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

[ussuri][tripleo][ironic][tftp] add --blocksize to tftp during installation
by Ruslanas Gžibovskis 20 May '21

20 May '21

Hi all, I wanted to ask, is there an option in tripleO to deploy undercloud tftp server with additional option, I had to add it to /usr/share/openstack-tripleo-heat-templates/deployment/ironic/ironic-pxe-container-puppet.yaml, so my container start cmd looks like this now: tripleoussuri/centos-binary-ironic-pxe:current-tripleo /bin/bash -c BIND_HOST=$(hiera ironic::pxe::tftp_bind_host -c /etc/puppet/hiera.yaml); /usr/sbin/in.tftpd --foreground --user root --address $BIND_HOST:69 --blocksize 1399 --m ap-file /var/lib/ironic/tftpboot/map-file /var/lib/ironic/tftpboot ironic_pxe_tftp But I believe it should be possibility with ExtraConfigUndercloud? I know, our network better should be fixed, but it will take several decades :) and while it will be fixed I want to automate deployment and it should be upgrade resistant :) Thanks for the advice in advance. -- Ruslanas Gžibovskis +370 6030 7030

1 0

[TripleO] tripleo-ci-centos-8-containers-multinode now using ephemeral Heat for master/wallaby
by James Slagle 20 May '21

20 May '21

For awareness, I wanted to point out that tripleo-ci-centos-8-containers-multinode is now using ephemeral Heat on the master and wallaby branches. This change[1] merged yesterday that made the switch. Of note, the Heat logs for the overcloud deployment are now under the directory undercloud/home/zuul/overcloud-deploy/overcloud/heat-launcher/log in the job logs. There is also a pending docs patch that covers a bit more how the feature works: https://review.opendev.org/c/openstack/tripleo-docs/+/783008 [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/777108 -- -- James Slagle --

1 0

Load back a vm to openstack
by Szabo, Istvan (Agoda) 20 May '21

20 May '21

Hi, I have 1 vm which was deleted from openstack but still have the libvirt xml so I can redefine it, I also have the instance disk file so I would like to know is there a way to load back to openstack the vm? Istvan Szabo Senior Infrastructure Engineer --------------------------------------------------- Agoda Services Co., Ltd. e: istvan.szabo(a)agoda.com<mailto:istvan.szabo@agoda.com> --------------------------------------------------- ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

2 1

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

19 May '21

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

1 1

[all][qa][cinder][octavia][murano] Devstack dropping support for Ubuntu Bionic 18.04
by Ghanshyam Mann 19 May '21

19 May '21

Hello Everyone, As per the testing runtime since Victoria [1], we need to move our CI/CD to Ubuntu Focal 20.04 but it seems there are few jobs still running on Bionic. As devstack team is planning to drop the Bionic support you need to move those to Focal otherwise they will start failing. We are planning to merge the devstack patch by 2nd week of May. - https://review.opendev.org/c/openstack/devstack/+/788754 I have not listed all the job but few of them which were failing with ' rtslib-fb-targetctl error' are below: Cinder- cinder-plugin-ceph-tempest-mn-aa - https://opendev.org/openstack/cinder/src/commit/7441694cd42111d8f24912f03f6… python-cinderclient - python-cinderclient-functional-py36 - https://review.opendev.org/c/openstack/python-cinderclient/+/788834 Octavia- https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/zuul… Murani- murano-dashboard-sanity-check -https://opendev.org/openstack/murano-dashboard/src/commit/b88b32abdffc171e6650450273004a41575d2d68/.zuul.yaml#L15 Also if your 3rd party CI is still running on Bionic, you can plan to migrate it to Focal before devstack patch merge. [1] https://governance.openstack.org/tc/reference/runtimes/victoria.html -gmann

10 24

Re: Freenode and libera.chat
by Gaël THEROND 19 May '21

19 May '21

Big +1 on my side too. Honestly, as someone else told it badly already, IRC is a nightmare to set and manage for anyone not coming from the 80/90s age of the internet. I do personally use it since decades and so I’m used to it BUT It’s not because I know how to use it that I’ll hide the truth. IRC and any client for it is challenging for any new comers. No, people don’t have to once again read and learn another tool just for our community. We’re in 2021 and things have improved a lot in terms of messaging systems, rich exchanges platforms emerged (With many opensource) and so I consider (as many others I bet) that as a community looking for diversity and inclusion it’s time to bring the community of existing and new contributors better tools, the messaging system revamp being one of the most important one to be reworked. I’m supporting (With another person from the internet) a small discord server of around 50 members and trying to answer many questions on reddit. Why did we setup such alternative? Because most of those people were young students thriving to get straight answers and support from the community. Why did they didn’t easily found answers? Because IRC channels are most of time dead towns (except for the kolla one) and that for people starting to learn Openstack it’s challenging to get access to IRC as it’s not as straightforward and feature rich as what alternatives messaging solutions can provide. It’s a matter of UI/UX, time consumed and amount of knowledge required to acquire just for one slightly simple/quick question. Same thing with the list by the way. I deeply think that if we want to continue to embark more new comers we will need alternatives for current communication platforms such as the IRCs channels and the list. Those are tools from the past. Sure they’re efficient, sure many of us know how to manage them but I really feel like adding another step to people trying to jump in isn’t a good way to welcome them. I perfectly know that some of us found it interesting as it kind of gates from «moronic» questions and it’s kind of seen as way to mark a tribal validation of your effort to join us, but in the meantime I think we’re loosing opportunities to bring more peoples in. It’s like in the real life, you’ll never want to use a tool or help someone that actually require you to follow a long and painful process before being able to help or use it. Sorry for the long message but I really wanted to explain the issue with those tools as one of my concerns actually surfaced today. PS: I don’t want us to join on Discord or any «SaaS solution » we can definitely host our own opensource alternative if we really want to gain autonomy on such topic.

1 0

[wallaby]nova, oslo.db or SQLAlchemy bug? "no attribute statement"
by tjoen 19 May '21

19 May '21

Python-3.9.4 nova-23.0.1 oslo.db-8.5.0 SQLAlchemy-1.4.15 docs.openstack.org/install-guide/launch-instance-provider.html $ openstack server list Status is SHUTDOWN $ openstack server start provider-instance results in site-packages/oslo_db/sqlalchemy/update_match.py", line 489, in _update_context.statement.froms[0] ERROR nova.api.openstack.wsgi AttributeError: 'QueryContext' object has no attribute 'statement' site-packages/oslo_db/sqlalchemy/update_match.py line 488 and 489: context = query._compile_context() primary_table = context.statement.froms[0] site-packages/sqlalchemy/orm/query.py def _compile_context(self, for_statement=False): compile_state = self._compile_state(for_statement=for_statement) context = QueryContext( context = QueryContext( compile_state, compile_state.statement, self._params, self.session, self.load_options, ) return context nova, oslo.db or SQLAlchemy bug?

3 4

[nova][train] live migration issue
by Ignazio Cassano 19 May '21

19 May '21

Hello Guys, on train centos7 I am facing live migration issue only for some instances (not all). The error reported is: 2021-05-19 08:45:57.096 142537 ERROR nova.compute.manager [-] [instance: b18450e8-b3db-4886-a737-c161d99c6a46] Live migration failed.: libvirtError: Unable to read from monitor: Connection reset by peer The instance remains in pause on both source and destination host. Any help,please ? Ignazio

2 3

[cinder] Bug deputy report for week of 2021-05-19
by Sofia Enriquez 19 May '21

19 May '21

Hello, This is a bug report from 2021-05-12 to 2021-05-19. You're welcome to join the next Cinder Bug Meeting later today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Critical:- High:- Medium: - https://bugs.launchpad.net/cinder/+bug/1928232 "Infinidat volume driver shouldn't use mock in production code". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1928400 "scheduler _create_snapshot filter_function fails when filtering on user_id or project_id". Unassigned. - https://bugs.launchpad.net/os-brick/+bug/1928944 "NVMe-oF connector returning the wrong nqn". Assigned to Gorka Eguileor. Low: - https://bugs.launchpad.net/cinder/+bug/1928929 "When using Brocade-FC-Zone-Driver with zoning_policy as initiator, attaching 2nd volume to a VM fails". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1928649 "Storwize/SVC driver report fast-formatting error when trying to edit the volume immediately after volume creation". Unassigned. Whishlist: - https://bugs.launchpad.net/cinder/+bug/1928431 "Add documentation for image-volume cache". Unassigned. Cheers, Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

OpenInfra Live - May 20 at 9am CT (1400 UTC)
by Erin Disney 19 May '21

19 May '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack community! Keeping up with new OpenStack releases can be a challenge. At a very large scale, it can be daunting. In this episode of OpenInfra.Live, operators from some of the largest OpenStack deployments at Blizzard Entertainment, OVH, Bloomberg, Workday, Vexxhost and CERN will explain their upgrades methodology, share their experience, and answer the questions of our live audience. Come hear from the best how they do it! Episode: Upgrades in Large Scale OpenStack Infrastructure Date and time: May 20 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=yf5iFiCg_Tw <https://www.youtube.com/watch?v=yf5iFiCg_Tw> LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6798703707925168128/ <https://www.linkedin.com/feed/update/urn:li:ugcPost:6798703707925168128/> Facebook: https://www.facebook.com/104139126308032/posts/3974109482644291/ <https://www.facebook.com/104139126308032/posts/3974109482644291/> WeChat: recording will be posted on OpenStack WeChat after the live stream Thanks, Erin Erin Disney Sr. Event Marketing Manager Open Infrastructure Foundation

1 0

[largescale-sig] OpenInfra.Live May 20: "Upgrades"
by Thierry Carrez 19 May '21

19 May '21

Hi everyone, For the last few months, the Large Scale SIG has been organizing video meetings around specific scaling topics, with operators of large scale deployments of OpenStack. We've decided to join forces with OpenInfra.Live and do future such meetings as OpenInfra.Live episodes. Tomorrow at 9am CT / 14:00 UTC we'll have the following live discussion: "Upgrades in Large Scale OpenStack infrastructure" including presentations from Belmiro Moreira (CERN), Arnaud Morin (OVHCloud), Mohammed Naser (Vexxhost), Imtiaz Chowdhury (Workday), Chris Morgan (Bloomberg) and Joshua Slater (Blizzard Entertainment). Come learn how those operators do it! The live audience will be able to ask questions to that awesome lineup of speakers, so don't miss the live show: https://www.youtube.com/watch?v=yf5iFiCg_Tw See you all tomorrow :) -- Thierry Carrez

1 0

cinder.volume.drivers.rbd connecting
by ManuParra 19 May '21

19 May '21

2 3

[interop] patches to review
by Kanevsky, Arkady 18 May '21

18 May '21

Team, Can use a few reviews on these: https://review.opendev.org/c/osf/interop/+/784622 https://review.opendev.org/c/osf/interop/+/789399 https://review.opendev.org/c/osf/interop/+/787646 Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[cinder] festival of XS reviews 21 April 2021
by Brian Rosmaita 18 May '21

18 May '21

Hello Cinder community members, This is a reminder that the most recent edition of the Cinder Festival of XS Reviews will be held at the end of this week on Friday 21 April. who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 21 April 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews This recurring meeting can be placed on your calendar by using this handy ICS file: http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics See you there! brian

1 1

[xena][neutron][ovn] Follow up to BGP with OVN PTG discussions
by Dan Sneddon 18 May '21

18 May '21

Thank you all who attended the discussions at the Xena PTG regarding BGP dynamic routing with Neutron using OVN. Here's a brief summary of the important points covered, and some background information. Red Hat has begun gathering a team of engineers to add OpenStack support for BGP dynamic routing using the Free Range Routing (FRR) set of daemons. Acting as a technical lead for the project, I led one session in the TripleO room to discuss the installer components and two sessions in the Neutron room to discuss BGP routing with OVN, and BGP EVPN with OVN. There was some feedback during the Neutron sessions that little has been done to engage the greater OpenStack/Neutron community thus far, or to utilize the existing RFE process for Neutron. This feedback was correct and was received. Initial work was done with a design that didn't require changes on Neutron/core OVN to start with. The intention is to create Neutron RFEs and to work with others working along similar lines now that we have some more clarity as to the direction of further efforts. There will likely be opportunities to leverage APIs and contribute to existing work being done with Neutron Dynamic Routing, BGPVPN, and other work being done to implement BGP EVPN. We would like to collaborate with Ericsson and others and come up with a solution that fits us all! The first steps involved greater changes to the deployment tooling, and this was proposed and reviewed upstream in the TripleO project: _ https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/triplo-bg… There are several use cases for using BGP, and in fact there are separate efforts underway to utilize BGP for the control plane and data plane. BGP may be used for equal-cost multipath (ECMP) load balancing of outbound links, and bi-directional forwarding detection (BFD) for resiliency to ensure that a path provides connectivity. For outbound connectivity BGP will learn routes from BGP peers. There is separate work being done to add BFD support for Neutron and Neutron Dynamic Routing, but this does not provide BFD support for host communication at the hypervisor layer. Using FRR at the host level provides this BFD support. BGP may be used for advertising routes to API endpoints. In this model HAProxy will listen on an IP address and FRR will advertise routes to that IP to BGP peers. High availability for HAProxy is provided via other means such as Pacemaker, and FRR will simply advertise the virtual IP address when it is active on an API controller. BGP may also be used for routing inbound traffic to provider network IPs or floating IPs for instance connectivity. The Compute nodes will run FRR to advertise routes to the local VM IPs or floating IPs hosted on the node. FRR has a daemon named Zebra that is responsible for exchanging routes between routing daemons such as BGP and the kernel. The redistribute connected statement in the FRR configuration will cause local IP addresses on the host to be advertised via BGP. Floating IP addresses are attached to a loopback interface in a namespace, so they will be redistributed using this method. Changes to OVN will be required to ensure provider network IPs assigned to VMs will be assigned to a loopback interface in a namespace in a similar fashion. FRR was selected for integration into TripleO and OVN for several reasons: using FRR leverages a proven production-grade routing solution that gives us BGP, BFD (bi-directional forwarding detection), VRFs for different namespaces for multitenancy, integration with kernel routing, and potentially other features such as OSPF, RPKI, route monitoring/mirroring, and more. FRR has a very complete feature set and is very robust, although there are other BGP speakers available such as ExaBGP or BIRD, and os-ken, with varying feature sets. OVN will need to be modified to enable the Compute node to assign VM provider network IPs to a loopback interface inside a namespace. These IP address will not be used for sending or receiving traffic, only for redistributing routes to the IPs to BGP peers. Traffic which is sent to those IP addresses will be forwarded to the VM using OVS flows on the hypervisor. An example agent for OVN has been written to demonstrate how to monitor the southbound OVN DB and create loopback IP addresses when a VM is started on a Compute node. The OVN changes will be detailed in a separate OVN spec. Demonstration code is available on Github: _ https://github.com/luis5tb/bgp-agent BGP EVPN with multitenancy will require separate VRFs per tenant. This will allow separate routing tables to be maintained, and allow for overlapping IP addresses for different Neutron tenant networks. FRR may have the capability to utilize a single BGP peering session to combine advertisements for all these VRFs, but there is still work to be done to prototype this design. This may result in more efficient BGP dynamic updates, and could potentially make troubleshooting more straightforward. As suggested in the PTG discussions, we are investigating the BGPVPN API. It appears that this API will work well for this use case. Hopefully we can make significant progress during the Xena development cycle, and we will be able to define what needs to be done in subsequent cycles. Any thoughts, suggestions, and contributions are appreciated. If anyone would like to review the work that we've already published, there is a series of blog posts that Luis Tomas Bolivar made related to how to use it on OpenStack and how it works: - OVN-BGP agent introduction: https://ltomasbo.wordpress.com/2021/02/04/openstack-networking-with-bgp/ - How to set ip up on DevStack Environment: https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ - In-depth traffic flow inspection: https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-in-depth-traffic-fl… Here are some relevant links to posts written by Luis Tomas Bolivar on the ovs-discuss mailing list: https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051029.html https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051031.html https://mail.openvswitch.org/pipermail/ovs-discuss/2021-March/051033.html -- Dan Sneddon | Senior Principal Software Engineer dsneddon(a)redhat.com | redhat.com/cloud dsneddon:irc | @dxs:twitter

2 1

[cinder][kolla][OSA][release] Wallaby cycle-trailing release deadline
by Herve Beraud 18 May '21

18 May '21

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Wallaby trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until July 02, 2021: https://releases.openstack.org/xena/schedule.html#x-cycle-trail <https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail> If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla openstack-ansible-roles openstack-ansible Thanks! Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[neutron]l3 vrotuer use dpdk ports making Forwarding performance too low
by yangkai 18 May '21

18 May '21

Hi,     I have a problem, when l3 vrouter use dpdk ports,  the performance is too low, eg: the bandwidth of vm's east-west. This is a aware issue? Have some solution if need l3 router and vm on one dpdk host? Best Regards, Yangkai

1 0

spice console configuration instead of vnc
by cloud learner 18 May '21

18 May '21

Dear Experts, I have installed Victoria On centos through packstack single node, i want to use spice console instead of vnc. And Installed the openstack-nova-spicehtml5proxy service and started and stop novncproxy service controller=10.1.75.20 In nova.conf [vnc] enabled=False [spice] agent_enabled = False enabled = True html5proxy_base_url = http://10.1.75.20:6082/spice_auto.html html5proxy_host = 0.0.0.0 html5proxy_port = 6082 keymap = en-us server_listen = 0.0.0.0 server_proxyclient_address = controller Above configuration made, but unable to get the spice console.. Kindly help

1 0

[neutron] Bug Deputy Report May 10 - 16th
by Oleg Bondarev 18 May '21

18 May '21

Hi everyone, Please find Bug Deputy report for the week May 10 - 16th below. Nothing Critical, just a few OVN bugs looking for triage from OVN folks (see the end of the list). Medium: - https://bugs.launchpad.net/neutron/+bug/1928345 - "neutron_tempest_plugin.api.test_trunk*" tests failing Edit o Assigned to Rodolfo Alonso o In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791255 - https://bugs.launchpad.net/neutron/+bug/1928299 - centos7 train vm live migration stops network on vm for some minutes o Unassigned o Incomplete: same issue as in https://bugs.launchpad.net/neutron/+bug/1815989 - https://bugs.launchpad.net/neutron/+bug/1928450 - ovn_migration.sh script doesn't detect neutron_dhcp agents when... o Fix released - https://bugs.launchpad.net/neutron/+bug/1928465 - Geneve allocation is not update during migration from ml2/ovs to ovn o Assigned to Jakub Libosvar o Fixed by https://review.opendev.org/c/openstack/neutron/+/784352, in progress for Wallaby - https://bugs.launchpad.net/neutron/+bug/1928466 - Allowed address pairs aren't populated to the new host with DVR router o Assigned to Slawek o In progress: https://review.opendev.org/c/openstack/neutron/+/791492 - https://bugs.launchpad.net/neutron/+bug/1927926 - Ha port is not cleared when cleanup l3router ns o Assigned to fanxiujian o Invalid Low: - https://bugs.launchpad.net/neutron/+bug/1928471 - Wrong assertion methods in unit test o Assigned to Takashi Natsume o Fix released - https://review.opendev.org/c/openstack/neutron/+/791497 Wishlist: - https://bugs.launchpad.net/neutron/+bug/1928211 - Remove quota "ConfDriver", deprecated in Liberty o Assigned to Rodolfo Alonso o In progress: https://review.opendev.org/c/openstack/neutron/+/790999 OVN Triage needed: - https://bugs.launchpad.net/neutron/+bug/1928330 - [OVN] Unable to ping router from test IPV6 subnet o Unassigned o New: OVN folks please triage - https://bugs.launchpad.net/neutron/+bug/1927977 - OVN IDLs not initialized for all worker types o Unassigned o New - https://bugs.launchpad.net/neutron/+bug/1928164 - [OVN] Ovn-controller dose not update the flows table when localport tap device is rebuilt o Unassigned o New Thanks, Oleg --- Advanced Software Technology Lab Huawei

1 0

[openstack-helm] Meeting Cancelled
by Gage Hugo 18 May '21

18 May '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow May 18th, the meeting is cancelled. Our next meeting will be May 25th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[Nova] Meeting time poll
by Artom Lifshitz 17 May '21

17 May '21

Hey all, As discussed during the IRC meeting today, the Red Hat Nova team would like to know if it's possible to shift the IRC meeting to a different day and/or time. This would facilitate our own internal calls, but I want to be very clear that we'll structure our internal calls around upstream, not the other way around. So please do not perceive any pressure to change, this is just a question :) To help us figure this out, I've created a Doodle poll [1]. I believe the regular attendees of the IRC meeting are spread between Central Europe and NA West Coast, so I've tried to list times that kinda make sense in both of those places, with a couple of hours on each side as a safety margin. Please vote on when you'd like the Nova IRC meeting to take place. Ignore the actual dates (like May 10), the important bits are the days of the week (Monday, Tuesday, etc). This is obviously a recurring meeting, something that Doodle doesn't seem to understand. I've not included Mondays and Wednesdays in the list of possibilities, as they would not work for Red Hat Nova. You can also vote to keep the status quo :) The times are listed in UTC, like the current meeting time, so unfortunately you have to be mindful of the effects of daylight savings time :( Thanks in advance! [1] https://doodle.com/poll/45ptnyn85iuw7pxz

1 2

Restart cinder-volume with Ceph rdb
by ManuParra 17 May '21

17 May '21

Dear OpenStack community, I have encountered a problem a few days ago and that is that when creating new volumes with: "openstack volume create --size 20 testmv" the volume creation status shows an error. If I go to the error log detail it indicates: "Schedule allocate volume: Could not find any available weighted backend". Indeed then I go to the cinder log and it indicates: "volume service is down - host: rbd:volumes@ceph-rbd”. I check with: "openstack volume service list” in which state are the services and I see that indeed this happens: | cinder-volume | rbd:volumes@ceph-rbd | nova | enabled | down | 2021-04-29T09:48:42.000000 | And stopped since 2021-04-29 ! I have checked Ceph (monitors,managers, osds. etc) and there are no problems with the Ceph BackEnd, everything is apparently working. This happened after an uncontrolled outage.So my question is how do I restart only cinder-volumes (I also have cinder-backup, cinder-scheduler but they are ok). Thank you very much in advance. Regards.

7 17

[stein][neutron] l3 agent error
by Ignazio Cassano 17 May '21

17 May '21

Hello Guys, I've just upgraded from openstack queens to rocky and then to stein on centos 7. In my configuration I have router high availability. After the upgrade and rebooting each controller one by one I get the following errors on all my 3 controllers under /var/log/neutron/l3-agent.log http://paste.openstack.org/show/805407/ If I run openstack router show for for one of uuid in the log: http://paste.openstack.org/show/805408/ Namespace for router in present on all 3 controllers. After the controllers reboot,some routers lost their routing tables, but restarting l3-agent they went ok. Is it possible router ha stopped working? Any idea,please ? Ignazio

2 3

[wallaby] patch needed for neutron-linuxbridge-agent: arp_protect.py
by tjoen 17 May '21

17 May '21

neutron-18.0.0 tenacity-7.0.0 Python-3.9.4 neutron-linuxbridge-agent exits with AttributeError: 'FileNotFoundError' object has no attribute 'returncode' neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py: .. @tenacity.retry( wait=tenacity.wait_exponential(multiplier=0.02), retry=tenacity.retry_if_exception(lambda e: e.returncode == 255), reraise=True ) .. Not a python programmer. But I guess it has something to do with Python39

2 2

[magnum] User meeting at 9:00 UTC Tuesday 18 May
by Bharat Kunwar 17 May '21

17 May '21

Hi all, We are planning to meet at 9:00 UTC Tuesday 18 May on #openstack-magnum (freenode). If you have anything pressing you’d like to discuss, please add to the agenda: https://etherpad.opendev.org/p/magnum-weekly-meeting <https://etherpad.opendev.org/p/magnum-weekly-meeting>. Cheers Bharat

1 1

[tripleo] TripleO CI Summary: Unified Sprint 43
by Bhagyashri Shewale 17 May '21

17 May '21

Greetings, The TripleO CI team has just completed **Unified Sprint 43** (Apr 8 thru to Apr 28 wed 2021). The following is a summary of completed work during this sprint cycle: - Successfully deployed promoter server for all c8 and c7 releases using new code (next gen) promoter code <https://hackmd.io/team/rh-openstack-ci?nav=search&q=promoter> - Continue to adopt new changes and improvements in the promoter : - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/32135 - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/32058 - Reduce our upstream resource usage with zuul jobs including optimizations across the zuul layouts in all the tripleo-* repos - https://review.opendev.org/q/topic:tripleo-ci-reduce - Removing Rocky jobs (EOL) - https://review.opendev.org/q/topic:%22tripleo-ci-reduce-rocky%22 - https://review.rdoproject.org/r/q/topic:%22tripleo-ci-reduce-rocky%22 - Content provider jobs across all branches - Wallaby branching -Component / integration rdo pipelines for wallaby - https://hackmd.io/2sxlx1XzTa-Te47_zLv42Q - Repo sanity check as part of the integration lines - https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/785040 - Correct the tagging in copy-quay tool - the copy and tagging was one single operation, now copy command is copying every hour all the hashes available and tag is running separately now collecting the current-tripleo tag directly from the delorean api. - copy-quay script: https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/32478 - Added all the monitoring work items for wallaby in Grafana: - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/32890 - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/33125 - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/33238 - Python version of cloud infra cleanup script - https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/31410 The planned work for the next sprint and leftover previous sprint work as following: - Deploy the promoter server for upstream promotions on vexxhost - Dependency Pipeline updates: - Update RHEL_U_Next to handle RHEL8.4 + ct3.0 + rhos-release scenario - elastic-recheck containerization - https://hackmd.io/dmxF-brbS-yg7tkFB_kxXQ - Openstack health for tripleo - https://hackmd.io/HQ5hyGAOSuG44Le2x6YzUw - Tripleo-repos spec and implementation - Adds tripleo-get-hash module get tripleo-ci hash info from tag - https://review.opendev.org/c/openstack/tripleo-ci/+/784392 - https://hackmd.io/v2jCX9RwSeuP8EEFDHRa8g?view - https://review.opendev.org/c/openstack/tripleo-specs/+/772442 - Tempest skiplist: Started to work on tempest-skiplist allowed list of tests (no patches yet) - Patrole stable release- Started to work on it - Ensure pip installs do not impact the tripleo deployment - https://review.opendev.org/q/topic:%22tqe_requires_cleanup%22 The Ruck and Rover for this sprint are Amol Kahat(akahat) and Pooja Jadhav(pojadhav). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd. Thanks, Bhagyashri Shewale

1 0

[all][tc] What's happening in Technical Committee: summary 14th May, 21: Reading: 5 min
by Ghanshyam Mann 17 May '21

17 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= Project updates: ------------------- ** puppet-glare is retired[1] Other updates: ------------------ ** Merged the 'Y' release naming process schedule[2]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-05-13-15.00.log.html * We will have next week's meeting on May 20th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[5]. Starting the 'Y' release naming process --------------------------------------------- * Y release naming process is started[6]. Nomination is open until June 10th feel free to propose names in below wiki ** https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Others --------- * Replacing ATC terminology with AC[7]. As UC is merged into TC, this is to include the AUC into ATC so that they can be eligible for TC election voting. We are having a good amount of discussion on Gerrit, feel free to review the patch if you have any points regarding this. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[8]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [9] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [10] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/790582 [2] https://review.opendev.org/c/openstack/governance/+/789385 [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html [7] https://review.opendev.org/c/openstack/governance/+/790092 [8] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [9] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [10] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[Octavia][Victoria] No service listening on port 9443 in the amphora instance
by Luke Camilleri 16 May '21

16 May '21

Hi there, i am trying to get Octavia running on a Victoria deployment on CentOS 8. It was a bit rough getting to the point to launch an instance mainly due to the load-balancer management network and the lack of documentation (https://docs.openstack.org/octavia/victoria/install/install.html) to deploy this oN CentOS. I will try to fix this once I have my deployment up and running to help others on the way installing and configuring this :-) At this point a LB can be launched by the tenant and the instance is spawned in the Octavia project and I can ping and SSH into the amphora instance from the Octavia node where the octavia-health-manager service is running using the IP within the same subnet of the amphoras (172.16.0.0/12). Unfortunately I keep on getting these errors in the log file of the worker log (/var/log/octavia/worker.log): 2021-05-05 01:54:49.368 14521 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.4.46', p ort=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f83e0181550>: Failed to establish a new connection: [Errno 111] Connection ref used',)) 2021-05-05 01:54:54.374 14521 ERROR octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection retries (currently set to 120) exhausted. The amphora is unavailable. Reason: HTTPSConnectionPool(host='172.16 .4.46', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f83e0181550>: Failed to establish a new connection: [Errno 111] Conne ction refused',)) 2021-05-05 01:54:54.374 14521 ERROR octavia.controller.worker.v1.tasks.amphora_driver_tasks [-] Amphora compute instance failed to become reachable. This either means the compute driver failed to fully boot the instance inside the timeout interval or the instance is not reachable via the lb-mgmt-net.: octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out obviously the instance is deleted then and the task fails from the tenant's perspective. The main issue here is that there is no service running on port 9443 on the amphora instance. I am assuming that this is in fact the amphora-agent service that is running on the instance which should be listening on this port 9443 but the service does not seem to be up or not installed at all. To create the image I have installed the CentOS package "openstack-octavia-diskimage-create" which provides the utility disk-image-create but from what I can conclude the amphora-agent is not being installed (thought this was done automatically by default :-( ) Can anyone let me know if the amphora-agent is what gets queried on port 9443 ? If the agent is not installed/injected by default when building the amphora image? The command to inject the amphora-agent into the amphora image when using the disk-image-create command? Thanks in advance for any assistance

2 10

[neutron][stein] l3 agent errors
by Ignazio Cassano 15 May '21

15 May '21

Hello Guys, I've just upgraded from openstack queens to rocky and then to stein on centos 7. In my configuration I have router high availability. After the upgrade I get the following errors on all my 3 controllers under /var/log/neutron/l3-agent.log 2021-05-15 19:04:28.599 13219 ERROR neutron.agent.linux.external_process [-] ip_monitor for router with uuid 8c137f17-52e6-47f9-bcaa-0eac94a9acd7 not found. The process should not have died 2021-05-15 19:04:28.600 13219 WARNING neutron.agent.linux.external_process [-] Respawning ip_monitor for uuid 8c137f17-52e6-47f9-bcaa-0eac94a9acd7 2021-05-15 19:04:29.905 13219 ERROR neutron.agent.linux.external_process [-] ip_monitor for router with uuid 303c88e4-1c94-4ebc-b592-91063b371db9 not found. The process should not have died 2021-05-15 19:04:29.905 13219 WARNING neutron.agent.linux.external_process [-] Respawning ip_monitor for uuid 303c88e4-1c94-4ebc-b592-91063b371db9 2021-05-15 19:04:31.267 13219 ERROR neutron.agent.linux.external_process [-] ip_monitor for router with uuid 103f3588-a775-4bca-b7a5-093a05068f64 not found. The process should not have died 2021-05-15 19:04:31.268 13219 WARNING neutron.agent.linux.external_process [-] Respawning ip_monitor for uuid 103f3588-a775-4bca-b7a5-093a05068f64 2021-05-15 19:04:32.684 13219 ERROR neutron.agent.linux.external_process [-] ip_monitor for router with uuid c6136e08-16a3-4d56-9440-59a7fe90d0b0 not found. The process should not have died 2021-05-15 19:04:32.685 13219 WARNING neutron.agent.linux.external_process [-] Respawning ip_monitor for uuid c6136e08-16a3-4d56-9440-59a7fe90d0b0 2021-05-15 19:04:34.140 13219 ERROR neutron.agent.linux.external_process [-] ip_monitor for router with uuid 9abaad3a-2439-4036-8611-5f93a8a3501f not found. The process should not have died 2021-05-15 19:04:34.140 13219 WARNING neutron.agent.linux.external_process [-] Respawning ip_monitor for uuid 9abaad3a-2439-4036-8611-5f93a8a3501f Getting for example the last uuid if I execute "openstack router show openstack router show 9abaad3a-2439-4036-8611-5f93a8a3501f +-------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | nova | | created_at | 2020-12-17T10:11:24Z | | description | | | distributed | False | | external_gateway_info | None | | flavor_id | None | | ha | True | | id | 9abaad3a-2439-4036-8611-5f93a8a3501f | | interfaces_info | [{"subnet_id": "a60b631d-d13c-4d02-a51b-2c86c0b38614", "ip_address": "192.168.201.1", "port_id": "08120fb0-be86-47a0-afd6-932801a2d194"}, {"subnet_id": "0ffcb170-66bb-4e65-9df0-80052deb1299", "ip_address": "169.254.192.11", "port_id": "3aa676aa-91cc-43c4-87ea-3b93340950ad"}, {"subnet_id": "0ffcb170-66bb-4e65-9df0-80052deb1299", "ip_address": "169.254.192.21", "port_id": "d5c0cff2-363d-470a-b77c-155d06e2654b"}, {"subnet_id": "0ffcb170-66bb-4e65-9df0-80052deb1299", "ip_address": "169.254.192.3", "port_id": "dab50b1a-d720-410a-b358-20c53a097bd7"}, {"subnet_id": "ae117b0e-fce9-42ca-88b3-a32ba239d795", "ip_address": "192.168.96.59", "port_id": "e49945aa-3e71-4f38-8c76-1c246cf18ff6"}] | | location | Munch({'project': Munch({'domain_name': None, 'domain_id': None, 'name': None, 'id': u'07573f587ceb4d9da007cec4ebc5dcf8'}), 'cloud': '', 'region_name': '', 'zone': None}) | | name | InternetGateway-a820a62fae-avz714-3-router | | project_id | 07573f587ceb4d9da007cec4ebc5dcf8 | | revision_number | 11 | | routes | destination='0.0.0.0/0', gateway='192.168.96.60' | | | destination='192.168.200.0/24', gateway='192.168.96.60' | | | destination='192.168.202.0/24', gateway='192.168.96.58' | | | destination='192.168.203.0/24', gateway='192.168.96.57' | | status | ACTIVE | | tags | | | updated_at | 2020-12-18T15:22:57Z | +-------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Namespace for router exists in all 3 controllers. Any idea, please ? Ignazio

1 0

[victoria] Windows Server 2008 SP2 - No bootble device
by SSelf＠performair.com 14 May '21

14 May '21

All; I'm having some trouble getting a Windows Server 2008 SP2 image to boot. On instance start I am greeted with the following: Booting from Hard Disk... Boot failed: not a bootable disk No bootable device. I've followed the instructions, referenced below, with a minor exception; the "Red Hat VirtIO SCSI controller" driver was installed after the OS had been installed as the Pre-installation Environment had troubles recognizing them (yay 2008?). Any recommendations would be welcome. Reference: https://superuser.openstack.org/articles/how-to-deploy-windows-on-openstack/ Thank you, Stephen Self IT Manager Perform Air International Inc. sself(a)performair.com www.performair.com

1 0

[horizon][stable] [release] Proposal to make stable/ocata and stable/pike as EOL
by vishal manchanda 14 May '21

14 May '21

Hi all, As discussed in the last horizon weekly meeting[1], [2] on 2021-05-05, I would like to announce that the horizon team decided to make stable/ocata and stable/pike branches as EOL. Consider this mail as an official announcement for that. I would like to know if anyone still would like to keep those branches to be open otherwise, I will purpose an EOL patch for these branches. Thanks & Regards, Vishal Manchanda [1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstac… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-ho…

1 0

Re: [release-announce] oslo.log 4.5.0
by Thomas Goirand 14 May '21

14 May '21

On 5/14/21 11:01 AM, no-reply(a)openstack.org wrote: > We enthusiastically announce the release of: > > oslo.log 4.5.0: oslo.log library > > The source is available from: > > https://opendev.org/openstack/oslo.log Hi, Something broke the subject line, as it's missing the "(xena)" thingy at the end... Can someone repair it, so my filters can properly work? Cheers, Thomas Goirand (zigo)

3 2

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

14 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 13 May '21

13 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

[Openstack][train][neutron] centos 7 after live migration instances stop to respond to ping
by Ignazio Cassano 12 May '21

12 May '21

Hello everyone, After migrating from stein to train, I am facing again with live migration issues because live migrated vm stop to respond to ping. On Stein I solved following a workaround for enabling legacy port binding. On centos 7 train I have not found any workaround for solving this issue yet. I think it is very important issue because train is the last release for centos 7 and it could be a bridge for moving from centos 7 to centos 8. I tried to talk on irc but seems some patches are not backported to train. So the question is: which is the strategy for moving from stein to a newer release ? On which version of openstack the multiport binding works fine in live migration case ? How can upgrade from stein to an openstack release where I can forget the above issue? Many thanks and Regards. Ignazio

1 0

[all][neutron][nova][ironic][cinder][keystone][glance][swift] OVN is now default in DevStack
by Lucas Alvares Gomes 12 May '21

12 May '21

Hi, As of today, OVN is the default network backend driver in DevStack [0]. This effort has been discussed in previous PTGs as well as emails to this mail list for a few cycles and now we are happy to announce that it's complete! We are aware that OpenStack is big and it has many projects included in it so, we tried to make this transition as smooth as possible for each other but, in case this change breaks your project CI in any way know that there's an easy fix for that which is explicitly enabling the ML2/OVS driver back until we can better investigate the problem. Here are some examples of patches doing it: [1][2][3]. Also, I would like to reinforce that this DOES NOT mean that the ML2/OVS driver will be deprecated, both drivers are and will be actively maintained by the Neutron community. Big thanks to everyone that participated in this effort! [0] https://review.opendev.org/c/openstack/devstack/+/735097/ [1] https://review.opendev.org/c/openstack/ironic/+/739945 [2] https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/790928 [3] https://review.opendev.org/c/openstack/metalsmith/+/749346 Cheers, Lucas

1 0

SNS like in Swift
by Antonio Gomez 12 May '21

12 May '21

Hi all, I'm trying to achieve an event based action based on uploading an Object to Swift, similar to SNS on AWS - where a file is uploaded and then some action happens. I've looked into https://github.com/openstack-archive/qinling due to https://www.youtube.com/watch?v=K2SiMZllN_A&t=30s&ab_channel=LingxianKong which shows how a function is triggered when a file is uploaded to Swift. However I see the project has been archived and not maintained and was wondering if there is something that maybe I can use? Thanks in advance, -- *Antonio Gomez *

1 0

[ironic] Announcing retirement of sushy-cli
by Riccardo Pittau 12 May '21

12 May '21

Hello ironicers! After a brief exchange in the ML and a discussion during the latest ironic meeting on monday, the community has agreed to retire the sushy-cli project. We'll start the procedure in the next days aiming to conclude the retirement during the xena cycle. Thank you, Cheers, Riccardo

1 0

[cinder] Bug deputy report for week of 2021-05-12
by Sofia Enriquez 12 May '21

12 May '21

Hello, This is a bug report from 2021-05-05 to 2021-05-12. You're welcome to join the next Cinder Bug Meeting later today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ------------------------------------------------------------------------------------------------------------ Critical: - https://bugs.launchpad.net/cinder/+bug/1928083 : "conditional_update broken in sqlalchemy 1.4". Assigned to Gorka Eguileor. High: Medium: - https://bugs.launchpad.net/cinder/+bug/1927784 : "NetApp ONTAP Failing Create FlexVol Pool Replica". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1927783 : "NetApp ONTAP Failing Create FlexVol Replica". Unassigned. - https://bugs.launchpad.net/os-brick/+bug/1928065: "Fails to create vm with nvme native multipath". Unassigned. Low:- Incomplete:- Cheers, Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[blazar] Proposing Jason Anderson as new core reviewer
by Pierre Riteau 12 May '21

12 May '21

Hello, Jason has been involved with the Blazar project for several years now. He has submitted useful new features and fixed bugs, and even wrote a couple of specs. I am proposing to add him as a core reviewer. If there is no objection, I will grant him +2 rights. Thank you Jason for your contributions! Best wishes, Pierre Riteau (priteau)

1 1

[all] Pycharm Project of the Decade - OpenStack
by ʂʍɒρƞįł Ҟưȴķɒʁʉɨ 12 May '21

12 May '21

Hello All, OpenStack recently voted the PyCharm project of the decade. Here's a latest blog article published on Jetbrains [1] [1] https://www.jetbrains.com/company/customers/experience/openstack/ Best Regards, Swapnil Kulkarni coolsvap at gmail dot com

1 0

[puppet] Lint job fails in some modules because of the latest lint packages
by Takashi Kajinami 12 May '21

12 May '21

Hello, I'd like to inform you that we are experiencing lint job failures in some modules since we removed pin of lint packages recently[1]. I started submitting fixes for these failures[2], so please be careful before you recheck the job. [1] https://review.opendev.org/c/openstack/puppet-openstack_spec_helper/+/761925 [2] https://review.opendev.org/q/topic:%22puppet-lint-latest%22+(status:open%20… Thank you, Takashi

1 1

[neutron] Specs to review
by Slawek Kaplonski 11 May '21

11 May '21

Hi, As we spoke on today's team meeting. I set review-priority = +1 for some of the specs which I think would be good to review. List is available at https:// tinyurl.com/22ct4dwx[1] Please take a look at those specs if You will have some time. Thx in advance. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://tinyurl.com/22ct4dwx

1 0

[all] Nomination open for OpenStack "Y" Release Naming until 10th June, 21
by Ghanshyam Mann 11 May '21

11 May '21

Hello Everyone, We are now starting the process for the OpenStack 'Y' release name. Below are the details on dates and criteria: Dates[1]: ======= - Nomination Open: 2021-05-13 to 2021-06-10 - TC Poll on proposed names: 2021-06-10 to 2021-06-17 Criteria: ====== - Refer to the below governance page for the naming criteria: https://governance.openstack.org/tc/reference/release-naming.html#release-n… - Any community members can propose the name to the below wiki page: https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals We encourage all community members to participate in this process. [1]https://governance.openstack.org/tc/reference/release-naming.html#polls -gmann

1 0

[ops][victoria][cinder] Import volume?
by DHilsbos＠performair.com 11 May '21

11 May '21

All; I'm looking to transfer several VMs from XenServer to an OpenStack Victoria cloud. Finding explanations for importing Glance images is easy, but I haven't been able to find a tutorial on importing Cinder volumes. Since they are currently independent servers / volumes it seems somewhat wasteful and messy to import each VMs disk as an image just to spawn a volume from it. We're using Ceph as the storage provider for Glance and Cinder. Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 5

[train][nova][neutron] gratiutous arp on centos 7
by Ignazio Cassano 11 May '21

11 May '21

Hello All, We've just updated openstack centos7 fron stein to train. Unfortunately live migrations works but vm lost a lot of pings after migration. We also applied the following patches but the do not solve: https://review.opendev.org/c/openstack/neutron/+/640258/ https://review.opendev.org/c/openstack/neutron/+/753314/ https://review.opendev.org/c/openstack/neutron/+/766277/ https://review.opendev.org/c/openstack/nova/+/742180/12 https://review.opendev.org/c/openstack/nova/+/747454/4 After that we also tried to apply https://review.opendev.org/c/openstack/nova/+/602432 but the issue remains the same. Please, anyone can help us ? Ignazio

1 0

[zun][horizon] How to display containers among VMs on network topology ?
by Maxime d'Estienne 11 May '21

11 May '21

Hello, I installed Zun on my stack and it works very well, I have a few containers up and running. I also added the zun-ui plugin for Horizon wich allows me to see the list of containers and to create them. But I often use the network topology view, wich I found very clean sometimes. I wondered if there is a solution to display the containers as are Vm's ? Thank you ! Maxime

2 2

[sdk]: identity service if get_application_credential method could use user name
by dmeng 11 May '21

11 May '21

Hello, Hope this email finds you well. Shall I please ask a question about the openstacksdk identity service, the application credential? We would like to get the expiration date of an application credential using the Identity v3 method get_application_credential or find_appplication_credential. We found that they require both the user id and the application credential id in order to get it. The code I'm using is as the following, and this works for us. conn = connection.Connection( session=sess, region_name='Victoria, identity_api_version='3') keystone = conn.identity find = keystone.get_application_credential(user='my_user_id', application_credential = 'app_cred_id') expire_date = find['expires_at'] We are wondering if we could use the user name to get it instead of the user id? If I do get_application_credential(user='catherine', application_credential = 'app_cred_id'), then it will show me an error that "You are not authorized to perform the requested action: identity:get_application_credential". Is there any method that no need user info, can just use the application credential id to get the expiration date? We also didn't find any documentation about the application credential in openstacksdk identity service docs. Thanks and have a great day! Catherine

2 5

Re: [cinder] Multiattach volume mount/attach limit
by Adam Tomas 11 May '21

11 May '21

Hi, thank you for the answer. Regards Adam > > Hi, > > This is currently not possible, and I believe there is no ongoing effort > to add this feature either. > > Cheers, > Gorka. > > >

1 0

[placement] clouds.yaml does not use placement API version variable
by jayaditya gupta 11 May '21

11 May '21

Even after specifying the variable in clouds.yaml placement still uses version 1.0 Story : https://storyboard.openstack.org/#!/story/2008553 Hello can someone help me on this one. I'm not sure where exactly is the issue in placement or in osc-placement . I would really appreciate the insight on this one. Thanks

1 0

[dev][tc]nova-scheduler: cpu-topology: sub-numa(numa nodes within one CPU socket) aware scheduler
by Song Bao Hua (Barry Song) 10 May '21

10 May '21

Dears, Historically, both AMD EPYC and Intel Xeon had NUMA nodes within one CPU socket. For Intel haswell/broadwell, they could have two rings to connect multiple CPUs: +----------------------------+ +-------------------------+ +---+ +-----+ +----+ +---+ +---+ +-----+ +----+ +---+ | | | | +---+ +-----+ +----+ ring +---+ +---+ ring +-----+ +----+ +---+ | | | | +---+ +-----+ +----+ +---+ +---+ +-----+ +----+ +---+ | | | | | | | | +----------------------------+ +-------------------------+ Due to the latency to access the memory located in different rings, cluster-on-die(COD) NUMA nodes did exist in haswell/ broadwell. For AMD EPYC, they used to have 4 DIEs in one CPU socket: +-------------------------------------------------+ | AMD EPYC | | +-------------+ +-------------+ | | | | | | | | | die | | die | | | | |-------- | | | | |\ /| | | | +-------------+ -\ /- +-------------+ | | | /-\ | | | +-------|------+/- -+-------|------+ | | | - | | | | | die | | die | | | | |------| | | | | | | | | | +--------------+ +--------------+ | | | +-------------------------------------------------+ These 4 different DIEs could be configured as 4 different NUMA. However, with the development of hardware, Intel and AMD no longer need to be aware of NUMA nodes within single one CPU. Intel has moved to mesh since skylake(server): +-------|-----------------------+ | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | +-------------------------------+ AMD moved memory and I/O to a separate DIE, thus made the whole CPU become UMA in EPYC II: +---------+ +---------+ +---------+ +---------+ | cpu die | |cpu die | |cpu die | |cpu die | | | | | | | | | +---------+ +---------+ +---------+ +---------+ +------------------------------------------------------+ | | | memory and I/O DIE | | | +------------------------------------------------------+ +---------+ +---------+ +---------+ +---------+ |cpu die | |cpu die | |cpu die | |cpu die | | | | | | | | | +---------+ +---------+ +---------+ +---------+ Skylake, while still having SNC(sub-numa-cluster) within a DIE for a huge mesh network, doesn't really suffer from this kind of internal sub-numa since the latency difference is really minor to enable SNC or not. According to "64-ia-32-architectures-optimization-manual"[1], for a typical 2P system, disabling and enabling SNC will bring minor latency difference for memory access within one CPU: SNC off: Using buffer size of 2000.000MB Measuring idle latencies (in ns)... Numa node Numa node 0 1 0 81.9 153.1 1 153.7 82.0 SNC on: Using buffer size of 2000.000MB Measuring idle latencies (in ns)... Numa node Numa node 0 1 2 3 0 81.6 89.4 140.4 153.6 1 86.5 78.5 144.3 162.8 2 142.3 153.0 81.6 89.3 3 144.5 162.8 85.5 77.4 As above, if we disable sub-numa in one CPU, the CPU has memory latency as 81.9, but if sub-numa is enabled, the advantage is really minor, SNC can access its own memory with the latency of 81.6 with 0.3 gap only. So SNC doesn't really matter on Xeon. However, the development of kunpeng920's topology is different from Intel and AMD. Similar with AMD EPYC, kunpeng920 has two DIEs in one CPU. Unlike EPYC which has only 8cores in each DIE, each DIE of kunpeng920 has 24 or 32 cores. For a typical 2P system, we can set it to 2NUMA or 4NUMA. +------------------------------+ +------------------------------+ | CPU | | CPU | | +----------+ +----------+ | | +----------+ +----------+ | | | | | | | | | | | | | | | DIE | | DIE | | | | DIE | | DIE | | | | | | | | | | | | | | | | | | | | | | | | | | | +----------+ +----------+ | | +----------+ +----------+ | | | | | +------------------------------+ +------------------------------+ * 2NUMA - DIE interleave In this case, two DIEs become one NUMA. The advantage is that we are getting more CPUs in one NUMA, so this decreases the fragment of CPUs and help deploy more virtual machines on the same host when we apply the rule of pinning VM within one NUMA, compared with disabling DIE interleave. But, this has some obvious disadvantage. Since we need to run DIE interleave, the average memory access latency could increase much. Enabling DIE interleave: Numa node Numa node 0 1 0 95.68 199.21 1 199.21 95.68 Disabling DIE interleave Numa node Numa node 0 1 2 3 0 85.79 104.33 189.95 209.00 1 104.33 85.79 209.00 229.60 2 189.95 209.00 85.79 104.33 3 209.00 229.60 104.33 85.79 As above, one DIE can access its local memory with latency of 85.79, but when die-interleave is enabled, the latency becomes 95.68. The gap 95.68-85.79 isn't minor. * 4NUMA - each DIE becomes one NUMA In this way, NUMA-aware software can access its local memory with much lower latency. Thus, we can gain some performance improvement in openstack if one VM is deployed in one DIE and only access its local memory. Testing has shown 4%+ performance improvement. However, under the rule that VM does not cross NUMA, less VMs could be deployed on the same host. In order to achieve both goals of performance improvement and anti-fragmentation, we are looking for some way of sub-numa awareness in openstack scheduler. That means, 1. we will disable DIE interleave, thus, for 2P system, we are going to have 4 NUMA; 2. we use the rule VM shouldn't cross CPU, thinking one CPU as a big NUMA and each DIE as a smaller sub-numa. 3. For guests, we can define different priorities, for high priority VMs whose performance is a great concern, openstack will try to deploy them in same sub-numa which is a DIE for kunpeng920; for low priority VMs who can endure across-die latency, they could be placed on different sub-numa, but still within same CPU. So basically, we'd like to make openstack aware of the topology of sub-numa within one cpu and support a rule which prevents cross-CPU but allows cross-DIE. At the same time, this scheduler should try its best to deploy important VMs in same sub-numa and allow relatively unimportant VMs to cross two sub-numa. This might be done by customized openstack flavor according to [2], but we are really looking for some flexible and automatic way. If openstack scheduler can recognize this kind of CPU topology and make smart decision accordingly, it would be nice. Please let me know how you think about it. And alternative ways also welcome. [1] https://software.intel.com/content/www/us/en/develop/download/intel-64-and-… [2] https://docs.openstack.org/nova/pike/admin/cpu-topologies.html Thanks Barry

1 0

Re: [ironic] IPA image does not want to boot with UEFI
by Julia Kreger 10 May '21

10 May '21

Adding the list back and trimming the message. Replies in-band. Well, that is good that the server is not signed, nor other esp images are not working. On Thu, Apr 1, 2021 at 11:20 AM Vuk Gojnic <vuk.gojnic(a)gmail.com> wrote: > > Hey Julia, > > Thanks for asking. I have tried with several ESP image options with same effect (one taken from Ubuntu Live ISO that boots on that node, another downloaded and third made with grub tools). None of them was signed. Interesting. At least it is consistent! Have you tried to pull down the iso image and take it apart to verify it is UEFI bootable against a VM or another physical machine? I'm wondering if you need both uefi parameters set. You definitely don't have properties['capabilities']['boot_mode'] set which is used or... maybe a better word to use is drawn in for asserting defaults, but you do have the deploy_boot_mode setting set. I guess a quick manual sanity check of the actual resulting iso image is going to be critical. Debug logging may also be useful, and I'm only thinking that because there is no logging from the generation of the image. > > The server is not in UEFI secure boot mode. Interesting, sure sounds like it is based on your original message. :( > Btw. I will be on holidays for next week so I might not be able to follow up on this discussion before Apr 12th. No worries, just ping us on irc.freenode.net in #openstack-ironic if a reply on the mailing list doesn't grab our attention. > > Bests, > Vuk > > On Thu, Apr 1, 2021 at 4:20 PM Julia Kreger <juliaashleykreger(a)gmail.com> wrote: >> >> Greetings, >> >> Two questions: >> 1) Are the ESP image contents signed, or are they built using one of >> the grub commands? >> 2) Is the machine set to enforce secure boot at this time? >> >> [trim]

2 3

[cinder] Multiattach volume mount/attach limit
by Adam Tomas 10 May '21

10 May '21

Hi, Is there any way to limit the number of possible mounts of multiattach volume? Best regards Adam Tomas

2 1

[tripleo][ci] all c8 master / wallaby blocked
by Wesley Hayutin 10 May '21

10 May '21

https://bugs.launchpad.net/tripleo/+bug/1927952 https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-8-content-prov… Issues atm w/ quay.io, we are making sure our failover is working properly atm. RDO was missing the latest ceph containers. Thanks

1 1

[swift][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: Swift tempurl middleware reveals signatures in the logfiles (CVE-2017-8761) https://launchpad.net/bugs/1685798 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[nova][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: tenant isolation is bypassed if port admin-state-up=false https://launchpad.net/bugs/1798904 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[neutron][security-sig] Please revisit your open vulnerability reports
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following reports: Anti-spoofing bypass using Open vSwitch (CVE-2021-20267) https://launchpad.net/bugs/1902917 Neutron RBAC not working for multiple extensions https://launchpad.net/bugs/1784259 tenant isolation is bypassed if port admin-state-up=false https://launchpad.net/bugs/1798904 non-IP ethertypes are permitted with iptables_hybrid firewall driver https://launchpad.net/bugs/1838473 RA Leak on tenant network https://launchpad.net/bugs/1844712 Anti-spoofing bypass https://launchpad.net/bugs/1884341 Can these be exploited by a nefarious actor, and if so, how? Are they likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[keystone][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: PCI-DSS account lock out DoS and account UUID lookup oracle https://launchpad.net/bugs/1688137 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[horizon][security-sig] Please revisit your open vulnerability reports
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following reports: using glance v2 api does not remove temporary files https://launchpad.net/bugs/1674846 DOS : API_RESULT_LIMIT does not work for swift objects https://launchpad.net/bugs/1724598 XSS in adding JavaScript into the ‘Subnet Name’ field https://launchpad.net/bugs/1892848 Can these be exploited by a nefarious actor, and if so, how? Are they likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[glance][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: default paste_deploy.flavor is none, but config file text implies it is 'keystone' (was: non-admin users can see all tenants' images even when image is private) https://launchpad.net/bugs/1799588 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[TripleO] next irc meeting Tuesday 11 May @ 1400 UTC in #tripleo
by Marios Andreou 10 May '21

10 May '21

Reminder that the next TripleO irc meeting is: ** Tuesday 11 May 1400 UTC in freenode irc channel: #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Apr 27 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-04-27-14.… Hope you can make it, regards, marios

1 0

[keystone] release notes for Victoria & wallaby?
by Ruby Loo 10 May '21

10 May '21

Hi, Where might I find out what changed in keystone in the wallaby release? I don't see any release notes for wallaby (or victoria) here: https://docs.openstack.org/releasenotes/keystone/. Thanks in advance, --ruby

2 2

[oslo] [tooz] Why does not tooz's tox env use upper-constraints?
by Radosław Piliszek 10 May '21

10 May '21

The question is the subject. Why does not tooz's tox env use upper-constraints? I asked this on IRC once some time ago but did not receive an answer so trying out ML as a more reliable medium. -yoctozepto

4 4

[nova] Getting compute nodes disabled by default
by Thomas Goirand 10 May '21

10 May '21

Hi Nova team, I was wondering if there was a way so that new compute nodes appear as disabled when they pop up. Indeed, the default workflow is that they first appear in the "nova" availability zone, and enabled by default. This doesn't really fit a production environment. I'd prefer if they could appear disabled, and if I had to enable them manually, when I'm finished running validity tests, and when my scripts have finished moving the new compute in the correct availability zone. Your thoughts? Cheers, Thomas Goirand (zigo)

2 2

[Multi-arch][SIG] Biweekly Meeting tomorrow at 0700 and 1500 UTC
by Rico Lin 10 May '21

10 May '21

Dear Multi-arch forks We will host our meeting tomorrow, please fill in the agenda [1] if you got anything you would like us to discuss about Here's our meeting schedule and location [2]: Tuesday at 0700 UTC in #openstack-meeting-alt Tuesday at 1500 UTC in #openstack-meeting [1] https://etherpad.opendev.org/p/Multi-Arch-agenda [2] http://eavesdrop.openstack.org/#Multi-Arch_SIG_Meeting *Rico Lin*

1 0

Nova db instance table node field where it comes from?
by Szabo, Istvan (Agoda) 10 May '21

10 May '21

Hello, Where this entry is coming from of an instance? I haven't found in the libvirt instance.xml and to be honest don't know where else to look. Thank you ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

1 0

[heat] [aodh] [autoscaling] [openstack victoria] How to setup aodh and heat to auto scale in openstack victoria based on cpu usage?
by Swogat Pradhan 10 May '21

10 May '21

Hi, How to set up aodh and heat to auto scale in openstack victoria based on cpu usage? As the metric cpu_util is now deprecated, how can someone use heat to auto scale up and down using cpu usage of the instance? I checked the ceilometer package and I could see the transformers are removed so i can't see any other way to perform arithmetic operations and generate cpu usage in percentage. Any insight is appreciated. with regards Swogat pradhan

1 1

[os-net-config] add VLAN interface to OVS bridge
by Tony Liu 10 May '21

10 May '21

Hi, I want to have a VLAN interface on a OVS bridge without tagging. Can that be done by os-net-config? I tried couple things. 1) Define a VLAN interface as a member of OVS bridge. In this case, VLAN interface is created and added on OVS bridge, but with the tag of VLAN ID. ``` {"network_config": [ { "type": "ovs_bridge", "name": "br-test", "use_dhcp": false, "addresses": [{"ip_netmask": "10.250.1.5/24"}], "members": [ { "type": "vlan", "device": "eno4", "vlan_id": 100, "primary": true } ] } ]} ``` 2) Define a VLAN interface out of OVS bridge and reference that VLAN interface as the type of "interface" in the member. This doesn't work unless the VLAN interface exists before running os-net-config. ``` {"network_config": [ { "type": "vlan", "vlan_id": 100, "device": "eno4", "addresses": [{"ip_netmask": "10.250.1.5/24"}] }, { "type": "ovs_bridge", "name": "br-test", "use_dhcp": false, "members": [ { "type": "interface", "name": "vlan100", "primary": true } ] } ]} ``` Anything else I can try? Thanks! Tony

1 0

[tripleo] nic config sample for OVN
by Tony Liu 10 May '21

10 May '21

Hi, Could anyone share a nic configuration template for OVN? In my case, the external interface is a VLAN interface. Thanks! Tony

1 0

[all][tc] What's happening in Technical Committee: summary 7th May, 21: Reading: 5 min
by Ghanshyam Mann 09 May '21

09 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= Project updates: ------------------- ** None for this week. Other updates: ------------------ ** Swift and Ironic added the 'assert:supports-standalone' tag. ** Update Nodejs Runtime to Nodejs14 From Nodejs10 for Xena Cycle[1] ** Reduced TC office hours to one per week[2] 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-05-06-15.00.log.html * We will have next week's meeting on May 13th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[5]. Starting the 'Y' release naming process --------------------------------------------- * Governance patch is up to finalize the dates for Y release naming process[6] * https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Others --------- * Replacing ATC terminology with AC[7]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[8]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [9] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [10] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022247.html [2] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] https://review.opendev.org/c/openstack/governance/+/789385 [7] https://review.opendev.org/c/openstack/governance/+/790092 [8] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [9] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [10] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[puppet] Propose retiring puppet-glare
by Takashi Kajinami 09 May '21

09 May '21

Hello, I'd like to propose retiring puppet-galre project, because the Glare[1] project looks inactive for a while based on the following three points - No actual development is made for 2 years - No release was made since the last Rocky release - setup.cfg is not maintained and the python versions listed are very outdated [1] https://opendev.org/x/glare I'll wait for 1-2 weeks to hear opinions from others. If anybody is interested in keeping the puppet-glare project or has intention to maintain Glare itself then please let me know. Thank you, Takashi

4 5

[devstack][infra] POST_FAILURE on export-devstack-journal : Export journal
by Martin Kopec 09 May '21

09 May '21

Hi, one of our jobs (python-tempestconf project) is frequently failing with POST_FAILURE [1] during the following task: export-devstack-journal : Export journal I'm bringing this to a broader audience as we're not sure where exactly the issue might be. Did you encounter a similar issue lately or in the past? [1] https://zuul.opendev.org/t/openstack/builds?job_name=python-tempestconf-tem… Thanks for any advice, -- Martin Kopec

4 10

[TripleO] Closed out wallaby milestone in Launchpad and moved bugs to xena-1
by Marios Andreou 07 May '21

07 May '21

Hello, I closed out the wallaby-rc1 milestone in launchpad and moved ongoing bugs over to xena-1 https://launchpad.net/tripleo/+milestone/xena-1 - info on the moved bugs @ [1] Thanks to tosky for pinging on tripleo about this: there were problems a while back with gerrit <--> launchpad integration so there are likely many bugs that should be in fix-released but weren't moved automatically after the related patches merged. Please take a moment to check the bugs assigned to you in https://launchpad.net/tripleo/+milestone/xena-1 and make sure the status reflects reality? regards, marios [1] https://gist.github.com/marios/b3155fe3b1318cc26bfa4bc15c764a26#gistcomment…

1 1

Proposing Cédric Jeanneret (Tengu) for tripleo-core
by James Slagle 07 May '21

07 May '21

I'm proposing we formally promote Cédric to full tripleo-core duties. He is already in the gerrit group with the understanding that his +2 is for validations. His experience and contributions have grown a lot since then, and I'd like to see that +2 expanded to all of TripleO. If there are no objections, we'll consider the change official at the end of next week. -- -- James Slagle --

24 24

[horizon] Support for Angular 1.8.x in Horizon (fixing Debian Bullseye)
by Thomas Goirand 06 May '21

06 May '21

Hi, In Debian Bullseye, we've noticed that the ssh keypair and Glance image panels are broken. We have python3-xstatic-angular that used to depends on libjs-angularjs, and that libjs-angularjs moved to 1.8.2. Therefore, Horizon in Bullseye appears broken. I have re-embedded Angula within the python3-xstatic-angular and ask the Debian release team for an unblock, but due to the fact that the Debian policy is to *not* allow twice the same library with different versions, I have little hope for this unblock request to be approved. See the discussion here: https://bugs.debian.org/988054 So my question is: how hard would it be to fix Horizon so that it could work with libjs-angularjs 1.8.2 ? Is there any patch already available for this? Cheers, Thomas Goirand (zigo)

2 2

[interop][cinder] review of next.json
by Brian Rosmaita 06 May '21

06 May '21

Hello Interop WG, We began a review of next.json [0] at yesterday's cinder meeting and a few issues came up. 1. The 'description' for the volumes capabilities should be updated; here's a patch: https://review.opendev.org/c/osf/interop/+/789940 2. Are capabilities that require an admin (or system-scoped) token still excluded? 3. Are capabilities that require multiple users for testing (for example, volume transfer) excluded? Thanks! [0] https://opendev.org/osf/interop/src/branch/master/next.json

2 1

[openstack-ansible] Keystone federation with OpenID needs shibboleth
by Taltavull Jean-Francois 06 May '21

06 May '21

Hi All, I'm trying to make keystone federation with openid connect work on an Ubuntu 20.04 + Victoria cloud deployed with OSA. Despite the fact that I use openid, shibboleth seems to be involved and I had to add "ShibCompatValidUser On" directive to the file "/etc/apache2/conf-available/shib.conf", by hand in the keystone lxc container, in order to successfully authenticate ("valid user: granted" an not "valid user: denied" in apache log file). Has anyone already experienced this use case ? Thanks and best regards, Jean-Francois

2 6

[cinder] save the date for xena midcycles
by Brian Rosmaita 06 May '21

06 May '21

At yesterday's cinder meeting, we selected the times for our virtual midcycles: midcycle-1: week R-18, Wednesday 2 June 2021, 1400-1600 UTC midcycle-2: week R-9, Wednesday 4 August 2021, 1400-1600 UTC Use this etherpad to propose topics: https://etherpad.opendev.org/p/cinder-xena-mid-cycles Connection info will be posted on the etherpad closer to the date of each midcycle. The midcycles will be recorded. cheers, brian

1 0

[devstack][installation] Trouble with devstack installation
by Lana DI NOIA 06 May '21

06 May '21

Hello, I encounter the following error when I run stack.sh: ERROR: Editable requirements are not allowed as constraints ++./stack.sh:main:752 err_trap ++./stack.sh:err_trap:530 local r=1 stack.sh failed: full log in /opt/stack/logs/stack.sh.log.2021-05-06-115934 Error on exit And a little higher I have this warning Attempting uninstall: pip Found existing installation: pip 21.1.1 Uninstalling pip-21.1.1: Successfully uninstalled pip-21.1.1 Successfully installed pip-21.1.1 WARNING: Running pip as root will break packages and permissions. You should install packages reliably by using venv: https://pip.pypa.io/warnings/venv Any idea why? Thanks

1 0

[largescale-sig] Next meeting: May 5, 15utc
by Thierry Carrez 06 May '21

06 May '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210505T15 A number of topics have already been added to the agenda, including discussing our OpenInfra.Live show on May 20. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[ironic] RFC: abandon sushy-cli?
by Dmitry Tantsur 06 May '21

06 May '21

Hi ironicers, sushy-cli was an attempt to create a redfish CLI based on sushy. The effort stopped long ago, and the project hasn't had a single meaningful change since Ussuri. There is an official Redfish CLI from DMTF, I don't think we have cycles to maintain an alternative one. If you would like to maintain sushy-cli, please speak up! Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

4 3

Rocky Linux for Openstack
by Wada Akor 06 May '21

06 May '21

Good day , Please I want to know when will openstack provide information on how to installation of openstack on Rocky Linux be available. Thanks & Regards

7 8

[manila][ptg] Xena PTG Summary
by Goutham Pacha Ravi 06 May '21

06 May '21

Hello Zorillas, and other interested Stackers! Sorry this is getting to you later than usual :) We concluded a productive Project Team Gathering on 23rd Apr '21. I'd like to thank everyone that participated as well as the friendly folks at the OpenInfra Foundation who worked hard to organize this event. The following is my summary of the proceedings. I've linked associated etherpads and resources to dig in further. Please feel free to follow up here or on freenode's #openstack-manila if you have any questions. == Day 1 - Apr 19, 2021, Mon == === Manila Retrospective === Topic Etherpad: https://etherpad.opendev.org/p/manila-wallaby-retrospective - interns and their mentors did a great job through Wallaby! Many accomplishments, thanks to the sponsoring organizations for their investment - the two Bugsquash events at M1 and M3 were very effective. - we added new core members (python-manilaclient, manila-tempest-plugin) - sub-teams (manila-ui, manilaclient and manila-tempest-plugin) increased focus on the individual projects and sped up reviews - good cross project collaboration with OpenStack QA, Horizon, NFS-Ganesha and Ceph communities - we discussed strategies to avoid reviewer burnout and performed health checks on the team growth initiatives we took up in the Wallaby cycle Actions: - need to get proactive about reviews so we can avoid burn-out at the end of the cycle - continue bug squash days in Xena - look for interested contributors to join the core maintainer team - bring up reviews in weekly meetings and assign review owners earlier than M-2 - contributors need to be reminded to help with reviews == Day 3 - Apr 21, 2021, Wed == === manila-tempest-plugin plans and update === - lkuchlan and vhari highlighted difficulties around "capabilities" testing that was exposed due to feature changes in the CephFS driver in the Wallaby cycle - optional feature testing requires rework, the configuration options and test strategy have gotten confusing over time - discussion continued on dropping testing for older API microversions where some optional features (snapshots, snapshot cloning) weren't really optional. It was agreed that this was overkill. The problem is specifically in share type extra-specs. If these are setup with API version >= 2.24, we could circumvent this: https://review.opendev.org/c/openstack/manila-tempest-plugin/+/785307. The only issue is that tests could theoretically be run against a cloud that doesn't support API version 2.24 (has to be Newton release or older). The team agreed that we could document this deficiency in the configuration file since Newton release has been EOL for a while. Actions: - review and merge the fix to share type extra-specs - rework existing "run_XYZZY_tests" and "capability_XYZZY_support" flags to "share-feature-enabled" section where these capabilities are always set when a feature is enabled - this is in-line with the way optional feature testing for other OpenStack services is done === Service Recovery === Topic Etherpad: https://etherpad.opendev.org/p/xena-ptg-manila-share-recovery-polling - gouthamr discussed the use cases and architectures needing to run manila-share in active-active HA - service recovery after failure needs to be coordinated to prevent metadata corruption - clustering services will provide coordination for cleanup - vendor driver authors will need to audit critical sections and replace oslo.concurrency locks with distributed locks. Actions: - there will be a specification submitted for review === Polling operations in manila-share === Topic Etherpad: https://etherpad.opendev.org/p/xena-ptg-manila-share-recovery-polling - haixin and gouthamr summarized the periodic tasks conducted by the share manager service - to update share service capabilities and real time capacity information, - to monitor the health of share replicas, - to "watch" the progress of long running clone, snapshot and migration operations. - these periodic tasks will be inefficiently duplicated if running across multiple nodes associated with the same backend storage system/driver - many of these periodic tasks are meant to be read-only, however, the health-check operations modify database state, currently these assume a single writer, and unless staggered, updates may be duplicated as well - proposed mitigation was to allow clustered hosts to ignore polling operations if one is in progress elsewhere, and for the service instance executing the tasks to distribute the workload to other hosts via the message queue - another issue with periodic tasks was the lack of ability to stop an unnecessary task from running - we could take advantage of oslo's threadgroup that exposes a start/stop API Actions: - replace loopingcall periodic tasks with threadgroups to selectively run periodic tasks - propose a specification to coordinate and distribute polling workloads === Interop Working Group === - arkady_kanevsky presented the mission of the InteropWG, and laid out plans for the upcoming Interop guideline - manila tests were added to the guideline as part of the 2020.11 guideline and have been available for the community to provide results - there was an optional capability (shrinking shares) that was flagged, and the team discussed if it was to remain flagged, or be moved to an advisory state - including reduction of the cutoff score - the team wants to stabilize the tests exposed through the next guideline, and work on a way to remove the necessity of an admin user to bootstrap the manila's tempest tests where unnecessary Actions: - improve manila tempest plugin to not request admin credentials for the tests exposed, and work with a configured "default" share type === Share server migration improvements === - share server migration was added as an experimental feature in the Victoria release - carloss presented use cases for nondisruptive share server migration - nondisruptive migration would mean that network changes are unnecessary, so the share manager needn't seek out any new network ports or relinquish existing ones - the share server migration is experimental, however, we'd still make nondisruptive migration possible only from a new API microversion - manual triggering of the second phase is still necessary to allow control of the cutover/switchover. All resources will continue to be tagged busy until the migration has been completed Actions: - no specification is necessary because the changes to the API and core manila are expected to be minimal === OpenStackSDK and Manila === - ashrod98, NicoleBU and markypharaoh, seniors at Boston University worked through the past cycle to expose manila resources to the OpenStackSDK - an outreachy internship proposal has been submitted to continue their work to expose more API functionality via the SDK - we'd prioritize common elements - quotas, limits and availability zones so we can parallely work on the OpenStackClient and Horizon implementation for these - need review attention on the patches Actions: - some domain reviewers for manila patches to be added to the OpenStackSDK core team to help with reviews == Day 4 - Apr 22, 2021, Thu == === Support soft delete/recycle bin functionality === - haixin told us that inspur cloud has a "soft-delete" functionality that they would like to contribute to upstream manila - the functionality allows users to recover deleted shares within a configurable time zone via Manila API - the proposal is to only allow soft-deletion and recovery of shares, but in the future this can be extended to other resources such as snapshots, replicas, share groups - soft deletions have the same validations as deletions currently do - quota implications and alternatives (unmanage, an system admin API) were discussed Actions: - a specification will be proposed for this work === New Driver Requirements and CI knowledge sharing === - there was a informative presentation from the Cinder PTG [3] about using Software Factory to deploy a Third Party CI system with Gerrit, Nodepool, Zuulv3 and other components - some helpful but unmaintained test hook code exists in the repos to aid with CI systems using devstack-gate - since devstack-gate has been deprecated for a long time, third party CIs are strongly recommended to move away from it Actions: - complete removal of devstack-gate related manila-tempest-plugin installation from manila's devstack plugin - create a Third Party CI and help wiki/doc that vendor driver maintainers can curate and contribute to === New Driver for Dell EMC PowerStore === - vb123 discussed Dell EMC powerstore storage, its capabilities and their work in cinder, and made a proposal for a driver in manila - this driver's being targeted for the Xena release: https://blueprints.launchpad.net/manila/+spec/powerstore-manila-driver - community shared updates and documentation from the Victoria and Wallaby cycles that may be helpful to the driver authors - driver submission deadlines have been published: https://releases.openstack.org/xena/schedule.html === Enabling access allow/deny for container driver with LDAP === - esantos and carloss enabled the container driver in the Wallaby release to support addition of and updates to LDAP security services - however, this work was just intended to expose a reference implementation to security services - the container driver does not validate access rules applied with the LDAP server today - the proposal is to enable validation in the driver when a security service is configured Actions: - publish container driver helper image to the manila-image-elements repository and explore container registries that community can use for the long term for CI and dev/test - file a bug and fix the missing LDAP validation in the container share driver === Keystone based user/cephx authentication === - "cephx" (CEPHFS) access types are not validated beyond their structure and syntax - with cephx access, an access key for the ceph client user can be retrieved via the access-list API call - access keys are privileged information, while we've always had a stance that Native CephFS is only suitable in trusted tenant environments, there's a desire to hide access keys from unrelated users in the project - gouthamr proposed that we allow deployers to choose if Keystone user identity validation must be performed - when validation is enabled, manila ensures that users may only allow share access to other users in their project - users may only retrieve access keys belonging to themselves, and no other project users - an alternative would be to keystone validation would be to allow controlling the access_key via a separate RBAC policy - with the alternative, we wouldn't be able to validate if the access to user is in the same project as the user requesting the access Actions: - a specification will be proposed, however, the work's not expected to be prioritized for Xena === Addressing Technical Debt === - we discussed tech debt that was piling up from the last couple of cycles and assigned owners to drive them to completion in the Xena cycle Actions: - python-manilaclient still relies on keystoneclient to perform auth, there's ongoing work from vkmc+gouthamr to replace this with keystoneauth [4] - code in manila relies on the retrying python library that is no longer maintained; kiwi36 will propose replacing the usage with tenacity with tbarron's help [5] - tbarron will be resurrecting a patch that removes old deprecated configuration options [6] - carloss will be picking up rootwrap-to-privsep migration === Unified Limits === Topic Etherpad: https://etherpad.opendev.org/p/unified-limits-ptg - kiwi36, our Outreachy intern, proposed the design for using keystone's unified limits in manila with the help of the oslo.limit library - he walked through the prototype using resource quotas and highlighted the differences with the current quota system - we discussed why nested quotas were preferable to user quotas Actions: - a release independent specification will be proposed for the community to review and continue this work - explore how share type quotas will be handled === Secure RBAC Follow up === - vhari presented the RBAC changes that were made in the Wallaby release, including support for the system scope and reader role - a tempest test strategy was discussed, along with improvements made to tempest itself to make test credential setup with the new default roles - there's no plan to enforce the new defaults in Xena, we'll take the release to stabilize the feature and turn on deprecation warnings indicating intent to switch to the new defaults in the Y release Actions: - vhari and lkuchlan will start working on the tempest tests - wrap up known issues with the new defaults and backport fixes to the Wallaby release - manila's admin model and user personas will be documented == Day 5 - Apr 23, 2021, Fri == === VirtIOFS plans and update === Topic Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-xptg-april-2021 - tbarron and lyarwood presented an update on the research that was done in the wallaby release wrt live attaching virtiofs volumes to running compute instances - qemu supports live attaches, the feature is coming to libvirt soon. live migration of instances with virtiofs volumes isn't supported yet - this is ongoing work in the qemu/kvm/libvirt communities - we discussed the connection initiation and information exchange between manila and nova, and what parts will be coordinated via the os-share library - there are as yet no anticipated changes to the manila API Actions: - continue working with the libvirt community to have the live-attach APIs added - a specification will be proposed to nova (and manila if changes are necessary to the manila API) === CephFS driver update === Topic Etherpad: https://etherpad.opendev.org/p/cephfs-driver-update-xena-ptg - vkmc presented the changes and new features in the cephfs driver in the wallaby cycle - the driver was overhauled to interact with ceph via the ceph-mgr daemon instead of the deprecated ceph_volume_client library - there's an upgrade impact going from victoria to wallaby. Deployers must consult the release notes [7] and the ceph driver documentation [8] prior to upgrading. Data path operations are unaffected during an upgrade: - ceph clusters must be running the latest version of the release they're on to allow the wallaby manila driver to communicate with the ceph cluster - the ceph user configured with the driver needs mgr "caps", and mds/osd privileges can be dropped/reduced [8] - we discussed dropping the use of dbus in the nfs-ganesha module, and using the "watch-url" approach that ganesha's ceph-fsal module provides - we also discussed ceph-adm and ceph-orch based deployment which replaces ceph-ansible and the impact that would have on ganesha configuration - ceph quincy will support active/active nfs-ganesha clusters (even with ceph-adm based deployment), we discussed manila side changes to take advantage of this feature === manilaclient and OpenStackClient plans and update === Topic Etherpad: https://etherpad.opendev.org/p/manila-osc-xena-ptg - maaritamm provided an update on our multi-cycle effort to gain parity between manila's shell client and the osc plugin - we made great progress in the wallaby cycle and covered all "user" related functionality that was requested - we discussed what's left, and sought community priority of the missing commands - we discussed deprecation of the manila shell client and only supporting the osc plugin - albeit addressing the "standalone" use case where "manila" can be used in place of "openstack share" if users desire - we could use help to add new commands, and to review code in the osc plugin Actions: - achieve complete feature parity between the two shell client implementations, deprecate the manila shell client === manila-ui plans and update === Topic Etherpad: https://etherpad.opendev.org/p/manila-ui-update-xena-ptg - disap, our Outreachy intern and vkmc, highlighted the changes made in the wallaby cycle - we lauded the cross-project collaboration that was renewed in this cycle to triage issues, and proactively work on incoming changes in horizon and elsewhere - manila-ui's microversion catchup is progressing slowly, but surely - we have another outreachy project proposal that overlaps with the xena cycle Actions: - continue to catch up to API feature functionality in the UI Thanks for staying with me so far! :) There were a number of items that we couldn't cover, that you can see on the PTG Planning etherpad [1], if you own those topics, please add them to the weekly IRC meeting agenda [2] and we can go over them. The meeting minutes etherpad continues to be available [9]. As usual, the whole PTG was recorded and posted on the OpenStack Manila Youtube channel [10] We had a great turn out and we heard from a diverse set of contributors, operators, interns and users from several affiliations and time zones. On behalf of the OpenStack Manila team, I deeply appreciate your time, and help in keeping the momentum on the project! Best, gouthamr [1] https://etherpad.opendev.org/p/xena-ptg-manila-planning [2] https://wiki.openstack.org/wiki/Manila/Meetings [3] https://www.youtube.com/watch?v=hVLpPBldn7g [4] https://review.opendev.org/647538 [5] https://review.opendev.org/380552 [6] https://review.opendev.org/745206/ [7] https://docs.openstack.org/releasenotes/manila/wallaby.html <https://docs.openstack.org/releasenotes/manila/wallaby.html> [8] https://docs.openstack.org/manila/wallaby/admin/cephfs_driver.html [9] https://etherpad.opendev.org/p/xena-ptg-manila [10] https://www.youtube.com/playlist?list=PLnpzT0InFrqDmsKKsF0MQKtv9fP4Oik17

1 0

[neutron] Drivers team meeting 07.05.2021 cancelled
by Slawek Kaplonski 06 May '21

06 May '21

Hi, Due to lack of new RFEs and any other topics, let's cancel tomorrow's meeting. Please use that time to review some of the already proposed specs: https:// review.opendev.org/q/project:openstack/neutron-specs+status:open[1] See You online :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/project:openstack/neutron-specs+status:open

1 0

[Octavia] 2021-05-12 weekly meeting cancelled
by Gregory Thiemonge 06 May '21

06 May '21

Hi, I'll be on PTO next Wednesday, I won't be able to run the meeting. We decided during yesterday's meeting that next week meeting is cancelled, Thanks, Greg

1 0

[wallaby][magnum] magnum-conductor Service down
by Ammad Syed 06 May '21

06 May '21

Hi, I am experiencing a problem in magnum 12.0.0 that conductor service randomly goes down. I am using ubuntu 20.04. root@controller ~(keystone_ubuntu20_new)# openstack coe service list +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | id | host | binary | state | disabled | disabled_reason | created_at | updated_at | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | 1 | None | magnum-conductor | down | False | None | 2021-05-03T10:33:16+00:00 | 2021-05-05T21:48:39+00:00 | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ checking the logs of last updated timestamp in /var/log/syslog. I have found below error. May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/kubernetes/client/apis/__init__.py:10: DeprecationWarning: The package kubernetes.client.apis is renamed and deprecated, use kubernetes.client.api instead (please note that the trailing s was removed). May 5 21:49:29 orchestration magnum-conductor[10827]: warnings.warn( May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: Traceback (most recent call last): May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/hub.py", line 476, in fire_timers May 5 21:49:29 orchestration magnum-conductor[10827]: timer() May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/timer.py", line 59, in __call__ May 5 21:49:29 orchestration magnum-conductor[10827]: cb(*args, **kw) May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/semaphore.py", line 152, in _do_acquire May 5 21:49:29 orchestration magnum-conductor[10827]: waiter.switch() May 5 21:49:29 orchestration magnum-conductor[10827]: greenlet.error: cannot switch to a different thread There is no logs in magnum-conductor.log after the last updated timestamp of conductor service. The service looks running if I see in ps -ef | grep magnum-conductor. - Ammad

1 0

[wallaby][neutron][ovn] Distributed FIP
by Malik Obaid 06 May '21

06 May '21

Hi, I am using Openstack Wallaby release on Ubuntu 20.04. I have enabled DVR and Distributed FIP on 1 controller node and 2 compute nodes, we have mapped an interface(ens224) with the physical network(br-eth1) using below command: ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth1 The issue I am facing here is that when I analyze the traffic on interface (ens224) while initializing ping from a VM on my compute node 1, it shows the traffic flowing through my controller as well as both the compute nodes rather than only flowing through compute node 1. I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

1 0

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

06 May '21

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

1 1

[ptl][release][stable][EM] Extended Maintenance - Train
by Előd Illés 05 May '21

05 May '21

Hi, As Wallaby was released the day before yesterday and we are in a less busy period, it is a good opportunity to call your attention to the following: In less than a month Train is planned to transition to Extended Maintenance phase [1] (planned date: 2021-05-12). I have generated the list of the current *open* and *unreleased* changes in stable/train for the follows-policy tagged repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Train before moving stable/train branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the*latest* (Train) *releases* of repositories with *train-em* tag. * After the transition stable/train will be still open for bug fixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/train-final-release-before-em

1 1

[TripleO] stable/wallaby branch for tripleo repos \o/ ping if problems :)
by Marios Andreou 05 May '21

05 May '21

Hello tripleo o/ now that https://review.opendev.org/c/openstack/releases/+/789558 merged (thanks elod & hberaud for reviews) we have a stable/wallaby branch for all tripleo repos (list at [1]). Note that for python-tripleoclient & tripleo-common the branch was previously created with [2] as part of our testing and preparation. Special thank you to all those involved from the tripleo-ci team - rlandy, baghyashris, ysandeep, ananya (frenzy_friday), pojadav and apologies to those I missed. Preparations started at least six weeks ago (i.e. the previous 2 sprints). If you are interested in our prep work there are some notes and pointers at [3]. So: * stable/wallaby for tripleo repos is now a thing \o/ * go ahead and post patches to stable/wallaby (you'll need those .gitreview things to merge first like [4]) * If there are issues with CI please reach out to tripleo-ci in freenode #tripleo or #oooq - especially ping the persons with |ruck or |rover in the irc nickname [5] I'll deal with the launchpad side of things next (moving ongoing bugs over from wallaby-rc1 to xena-1 etc), regards, marios [1] https://releases.openstack.org/teams/tripleo.html#wallaby [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021741.ht… [3] https://hackmd.io/2sxlx1XzTa-Te47_zLv42Q?view [4] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/789889 [5] https://docs.openstack.org/tripleo-docs/latest/ci/ruck_rover_primer.html

2 2

[TripleO] stable/wallaby branching
by Marios Andreou 05 May '21

05 May '21

Hello TripleO, quick update on the plan for stable/wallaby branching. The goal is to release tripleo stable/wallaby just after PTG i.e. last week of April. The tripleo-ci team have spent the previous sprint preparing and we now have the integration and component pipelines in place [1][2]. As of today we should also have the upstream check/gate multinode branchful jobs. We are planning to use this current sprint to resolve issues and ensure we have the CI coverage in place so we can safely release all the tripleo things. As we usually do, we are going to first branch python-tripleoclient and tripleo-common so we can exercise and sanity check the CI jobs. The stable/wallaby for client and common will appear after we merge [3]. *** PLEASE AVOID *** posting patches to stable/wallaby python-tripleoclient or tripleo-common until the CI team has completed our testing. Basically until we are ready to create a stable/wallaby for all the tripleo things (which will be announced in due course). Obviously as always please speak up if you disagree with any of the above or if something doesn't make sense or if you have any concerns about the proposed timings regards, marios [1] https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-integ… [2] https://review.rdoproject.org/zuul/builds?pipeline=openstack-component-trip… [3] https://review.opendev.org/c/openstack/releases/+/785670

1 1

[infra] Retiring the LimeSurvey instance at survey.openstack.org
by Jeremy Stanley 05 May '21

05 May '21

We are retiring our beta-test LimeSurvey service that was running on survey.openstack.org, as well as decommissioning the server itself, some time later today. Our survey service never saw production use. It was a compelling idea, but the prevalence of free surveys-as-a-service options (a number of which are built with open source software) meant that the only real benefit to running our own was that we didn't need to entrust the response data to third party organizations. As a result, there's been very limited use of the offering and in order to redirect our limited time and resources to services where we can provide the most benefit to our communities, we're ending this one. -- Jeremy Stanley

1 0