- openstack-discuss - lists.openstack.org

Cleanup database(s)
by Eugen Block 09 Mar '21

09 Mar '21

Hi *, I have a quick question, last year we migrated our OpenStack to a highly available environment through a reinstall of all nodes. The migration went quite well, we're working happily in the new cloud but the databases still contain deprecated data. For example, the nova-scheduler logs lines like these on a regular basis: /var/log/nova/nova-scheduler.log:2021-02-19 12:02:46.439 23540 WARNING nova.scheduler.host_manager [...] No compute service record found for host compute1 This is one of the old compute nodes that has been reinstalled and is now compute01. I tried to find the right spot to delete some lines in the DB but there are a couple of places so I wanted to check and ask you for some insights. The scheduler messages seem to originate in /usr/lib/python3.6/site-packages/nova/scheduler/host_manager.py ---snip--- for cell_uuid, computes in compute_nodes.items(): for compute in computes: service = services.get(compute.host) if not service: LOG.warning( "No compute service record found for host %(host)s", {'host': compute.host}) continue ---snip--- So I figured it could be this table in the nova DB: ---snip--- MariaDB [nova]> select host,deleted from compute_nodes; +-----------+---------+ | host | deleted | +-----------+---------+ | compute01 | 0 | | compute02 | 0 | | compute03 | 0 | | compute04 | 0 | | compute05 | 0 | | compute1 | 0 | | compute2 | 0 | | compute3 | 0 | | compute4 | 0 | +-----------+---------+ ---snip--- What would be the best approach here to clean up a little? I believe it would be safe to simply purge those lines containing the old compute node, but there might be a smoother way. Or maybe there are more places to purge old data from? I'd appreciate any ideas. Regards, Eugen

2 8

[election][blazar] PTL candidacy for Xena
by Pierre Riteau 09 Mar '21

09 Mar '21

Hi, I would like to self-nominate for the role of PTL of Blazar for the Xena release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain the Blazar software for their use cases and encourage the addition of new functionalities. Thank you for your support, Pierre Riteau (priteau)

1 0

[election][storlets] PTL Candidacy for Xena
by Takashi Kajinami 09 Mar '21

09 Mar '21

Hi All, I'd like to announce my candidacy to continue the PTL role for Storlets project in the Xena cycle. Because we currently don't have very active development in Storlets project, I'll propose we mainly focus on the following two items during the next cycle. - Improve stability of our code - Keep compatibility with the latest items - Latest Swift - Latest Ubuntu LTS In addition, I'll initiate some discussion about our future release and management model, considering decreasing resources for reviews and developments. Thank you for your consideration. Thank you, Takashi

1 0

[election][kolla] PTL candidacy for Xena
by Mark Goddard 09 Mar '21

09 Mar '21

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Xena cycle. I have been PTL for the last 4 cycles, and would like the opportunity to continue to lead the team. Overall I think that the project is moving in the right direction. Some things that I think we should focus on in the next cycle are: * remove our dependency on Dockerhub in CI testing to avoid pull limits * improve the documentation * expand the core team Thanks for reading, Mark Goddard (mgoddard)

1 0

How to Handle RabbitMQ peak after restarting neutron-openvswitch-agent
by MaSch 08 Mar '21

08 Mar '21

Hello at all. After adding an new direct attached VLAN to our computeNodes and restarting neutron-openvswitch-agent, we detected a huge peak in RabbitMQ Messages. Mostly "neutron-vo-Port-1.1_fanout" these messages seem every node produced 5000+ Messages. Due to a bridge_mapping mismatch, the agent repeatedly restarted and produced more and more Messages. At the peak there were about 2Million messages in the queue. As we ran into Network issues caused by Messaging timeouts i would like to know if there is a procedure to handle this messages. Is it save to delete the queue as those messages? It seems they disappeared after a timeout period of about 30 Minutes. are currently using OpenStack Queens release. Thanks a lot in advance. Best regards MaSch

1 0

[election][charms] PTL candidacy for Xena
by Chris MacNaughton 08 Mar '21

08 Mar '21

Hello all, I would like to announce my candidacy for PTL of the OpenStack Charms project[1] for the Xena cycle. Through my time contributing to the OpenStack Charms project as a core team member, I have experienced working on many of the charms in both a bug-fix and new feature capacity. Additionally, I have made upstream contributions as needed. The OpenStack Charms project has an increasing community both consuming the charms, as well as contributing to them, and I think that it is important to actively nurture this community. In addition to our user community, it is important for OpenStack Charms members to integrate more widely in the wider OpenStack community. [1]: https://review.openstack.org/#/c/641571/ -- Chris MacNaughton

1 0

openstack:How to create "admin read only " role in openstack
by sandeep singh parihar 08 Mar '21

08 Mar '21

Hi, can someone please help to "How to create admin read only role " in openstack? Thanks sandeep

1 0

[election][cinder] PTL candidacy for Xena
by Brian Rosmaita 08 Mar '21

08 Mar '21

Hello everyone, I'd like to announce my candidacy for Cinder PTL for the Xena cycle. The primary challenge we face in the Cinder community is that our reviewing bandwidth has declined at the same time third-party driver contributions--new drivers, new features for existing drivers, and driver bugfixes--have been increasing. Similarly, we've been adding better CI coverage (good) while at the same time our gate jobs have become increasingly unstable (not due to the new tests, there are some old failures which seem to be occurring more often). We need to add some new core reviewers in Xena. Luckily, some people have been increasing their review participation recently, so there are community members getting themselves into a position to help the project in this capacity. (And anyone else currently working on cinder project who's interested becoming a cinder core, please contact me (or any of the current cores) to discuss what the expectations are.) We'll also be making it a priority to improve the gate jobs (or else we'll never be able to get anything merged). As far as community activity goes, the multiple virtual mid-cycle meetings have continued to be productive, and the cinder meeting in videoconference that we've been having once a month seems popular and gives us a break from the strict IRC meeting format. There's support to make the Festival of XS Reviews a recurring event, and Sofia has proposed holding a separate (short) bug meeting which we'll start doing soon. Hopefully all these events will help keep current contributors engaged and make it easier for other people to participate more fully. With respect to the details of Cinder development in Xena, I expect those to emerge from our virtual PTG discussions in April. You can help set the agenda here: https://etherpad.opendev.org/p/xena-ptg-cinder-planning Thanks for reading this far, and thank you for your consideration. Brian Rosmaita (rosmaita) https://review.opendev.org/c/openstack/election/+/779425

1 0

[election][horizon] PTL candidacy for Xena
by vishal manchanda 08 Mar '21

08 Mar '21

Hi everyone, I would like to announce my candidacy for PTL of Horizon for Xena release. I have been actively contributing to Horizon from stein release [1] and become horizon core reviewer in early train release. During these years, my focus was on filing horizon feature-gap [2], bug-fixing, and stabilizing horizon and its plugins. I am very grateful to all the people that have mentored me and helped me throughout these years. As a PTL I will focus on the following areas: * Migrate horizon & its plugins to the next LTS version of both Django and Nodejs. * Focus on specific set of features-gap instead of targeting all or many at a time. For example, 'System Scope Support' is one of the highest priority we should do in Xena cycle. * Reduce the number of New/Open bugs which is high currently. Something we can do weekly basis in rotation basis or together in meeting etc. * Help new contributors to work on the horizon. I am looking forward to working together with all of you on the Xena release. Thank you, Vishal Manchanda(irc: vishalmanchanda) [1] https://www.stackalytics.io/?metric=commits&release=all&user_id=vishalmanch… [2] https://etherpad.opendev.org/p/horizon-feature-gap

1 0

[election][trove] PTL candidacy for Xena
by Lingxian Kong 08 Mar '21

08 Mar '21

Hi community, I am still very glad to announce my PTL candidacy for Trove, the database-as-a-service in OpenStack. I've been served as Trove PTL since Train release and I spent more than 50% of my working time on this project. I'm so lucky to work for a company that built a public cloud based on OpenStack and has been investing heavily in Open Source since day one. We also deployed Trove in our production, we report bug and fix in the upstream, we don't maintain private changes, we keep growing together with the community. --- Lingxian Kong Senior Cloud Engineer (Catalyst Cloud) Trove PTL (OpenStack) OpenStack Cloud Provider Co-Lead (Kubernetes)

1 0

[TripleO] stable/rocky End Of Life - closed for new code
by Marios Andreou 08 Mar '21

08 Mar '21

hello TripleO FYI we have now merged https://review.opendev.org/c/openstack/releases/+/774244 which tags stable/rocky for tripleo repos as End Of Life. *** WE ARE NO LONGER ACCEPTING PATCHES *** for tripleo stable/rocky [1]. In due course the rocky branch will be removed from all tripleO repos, however this will not be possible if there are pending patches open against any of those [1]. So please avoid posting anything to tripleo stable/rocky and if you see a review posted please help by commenting and informing the author that rocky is closed for tripleo. thank you for reading and your help in this matter regards, marios [1] https://releases.openstack.org/teams/tripleo.html#rocky

2 1

[all][elections][ptl][tc] Combined PTL/TC Nominations Last Days
by Kendall Nelson 08 Mar '21

08 Mar '21

Hello All! A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Mar 09, 2021 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2021-03-02 23:45:00 UTC Nominations end @ 2021-03-09 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 1 day, 0:48:52 Nominations progress : 85.23% --------------------------------------------------- Projects[1] : 49 Projects with candidates : 22 ( 44.90%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 27 (Adjutant Barbican Blazar Cinder Cloudkitty Cyborg Designate Horizon Keystone Kolla Magnum Masakari Mistral Monasca OpenStackAnsible OpenStack_Charms Openstack_Chef Quality_Assurance Rally Requirements Senlin Storlets Swift Telemetry Vitrage Zaqar Zun) =================================================== Stats gathered @ 2021-03-08 22:56:08 UTC This means that with approximately 2 days left, 27 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, -Kendall Nelson (diablo_rojo) & the Election Officials [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for… __________________________

1 0

[all][qa] Gate failure for <= stable/train and Tempest master gate (Do not recheck)
by Ghanshyam Mann 08 Mar '21

08 Mar '21

Hello Everyone, get-pip.py url for py2.7 has been changed which causing failure on stable/train or older branches and Tempest master gate. Thanks, Dan, Elod for fixing and backporting those. Please wait for the below fixes to merge and do not recheck. https://review.opendev.org/q/Id62e91b1609db4b1d2fa425010bac1ce77e9fc51 -gmann

1 1

[election][designate] PTL candidacy for Xena
by Michael Johnson 08 Mar '21

08 Mar '21

Hello OpenStack community, I would like to announce my candidacy for PTL of Designate for the Xena cycle. The Wallaby release cycle seems like it went by very quickly and I would like to continue to support the Designate team during the Xena release. Thank you for your support and your consideration for Xena, Michael Johnson (johnsom)

1 0

[cinder] Bug deputy report for week of 2021-03-01
by Sofia Enriquez 08 Mar '21

08 Mar '21

This is a bug report from 2021-03-03 to 2021-03-08. Looks like we have a lot of things going on. Some of these bugs were discussed at the Cinder meeting last Wednesday 2021-02-24. Critical: - High: - https://bugs.launchpad.net/cinder/+bug/1916980: "Cinder sends old db object when delete an attachment ''. Assigned to Gorka Eguileor (gorka). - https://bugs.launchpad.net/cinder/+bug/1917450: "Automatic quota refresh counting twice migrating volumes". Assigned to Gorka Eguileor (gorka). - https://bugs.launchpad.net/cinder/+bug/1917287: "Ambiguous error logs for retype of inspur storage volume". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1917353: "image_conversion_cpu_limit and image_conversion_address_space_limit settings ignored in /etc/cinder/cinder.conf". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1917574: "Cannot show volumes with name for non-admins". Assigned to Rajat Dhasmana. Medium: - https://bugs.launchpad.net/cinder/+bug/1918099: " Nimble revert to snapshot bug". Assigned to Ajitha Robert (ajitharobert01). Low: - https://bugs.launchpad.net/cinder/+bug/1917293: "Scheduling is not even among multiple thin provisioning pools which have different sizes". Unassigned. Incomplete: - https://bugs.launchpad.net/cinder/+bug/1916843: " Backup create failed: RBD volume flatten too long causing mq to timed out." Unassigned. Undecided/Unconfirmed: - https://bugs.launchpad.net/cinder/+bug/1918119: "Volume backup timeout for large volumes". Assigned to Kiran Pawar (kiranpawar89). - https://bugs.launchpad.net/cinder/+bug/1918102: "Cinder-backup progress notification has incorrect percentage." Assigned to Jon Cui (czl389). - https://bugs.launchpad.net/cinder/+bug/1917797: "Cinder request to glance does not support TLS". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1917795: "Cinder ignores reader role conventions in default policies". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1917750: " Running parallel iSCSI/LVM c-vol backends is causing random failures in CI". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1917605: "Bulk create Hyperswap volume is failing". Assigned to Girish Chilukur. Not a bug:- Feel free to reply/reach me if I missed something. Regards 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

[Manila ] Bug squash happening next week starting Monday March 15th
by Vida Haririan 08 Mar '21

08 Mar '21

Hi all, We are planning a new Bug Squash event for next week. The event will be held from 15th through 18th March, 2021, providing plenty of time for all interested to participate. There will be a synchronous bug triage/review call held simultaneously on our Freenode channel #openstack-manila on 18th March, 2021 at 15:00 UTC and on this Jitsi bridge [1]. A list of selected bugs will be provided in advance here [2]. As always, please feel free to update the list with any bugs that you would like us to focus on during this period. Looking forward to you joining us for this event and many thanks in advance for your participation. :) Regards, Vida [1] https://meetpad.opendev.org/ManilaW-ReleaseBugSquash-II [2] https://ethercalc.openstack.org/hrs8m6sqpmaz

1 0

[election][tacker] PTL candidacy for Xena
by Yasufumi Ogawa 08 Mar '21

08 Mar '21

Hi, I'd like to propose my candidacy for Tacker PTL in Xena cycle. In Wallaby release, we have released several features for the latest ETSI NFV standard while largely updating infras, such as moving to Ubuntu 20.04, supporting redhat distros again and dropping python2 completely for not only Tacker but also related projects such as tosca-parser or heat-translator or so [1]. In addition, we have fixed instability in unit and functional tests for which we have troubles several times. As Tacker PTL, I've led the team by proposing not only new features, but also things for driving the team such as documentation or bug tracking. In Xena cycle, I would like to continue to make Tacker be more useful product for users interested in NFV. I believe Tacker will be a good reference implementation for NFV standard. We have planed to make Tacker more feasible not only for VM environment, but also container to meet requirements from industries. - Continue to implement the latest container technology with ETSI NFV standard. - Introduce multi API versions to meet the requirements for operators enable to deploy mixed environment of multi-vendor products in which some products provide a stable version APIs while other products adopt move advanced ones. - Proceed to design and implement test framework under development in ETSI NFV TST to improve the quality of the product, not only unit tests and functional tests, but also introduce more sophisticated scheme such as robot framework. [1] https://docs.openstack.org/releasenotes/tacker/unreleased.html Regards, Yasufumi Ogawa

1 0

[election][kuryr] PTL Candidacy for Xena
by Maysa De Macedo Souza 08 Mar '21

08 Mar '21

Greetings, I would like to continue serving as Kuryr PTL for the Xena cycle. I have been contributing to the OpenStack community since the Queens release and started serving as Kuryr PTL in the Wallaby cycle. It was a great opportunity to contribute back to the community as PTL and I would like to continue doing that. In wallaby we achieved the following goals: * Improved CI stability and fixed broken gates e.g. Network Policy e2e and OVN gates. * Added new testing scenarios for Services without selectors and Services with sctp. * Extended Kuryr functionalities - we started the dual-stack support and included the support for SCTP and Service without selectors. * Increased the contributor base with new contributors from the Outreachy program. For the next cycle, I propose the following goals for Kuryr: * Improve and extend CI: we already did great improvements, but we must continuously work on it to provide better and quicker feedback during the development process. As part of that, we plan to: update gates to start using Kubeadm and include a new cri-o gate. * Extend Kuryr functionalities: Support dual stack and Kubeadm for DevStack installations, and move Pools management to CRDs. * Continue growing the contributor base. Thanks, Maysa Macedo. IRC: maysams

1 0

Openstack Cinder support matrix
by DANILO PAOLO DELL'ORTO 08 Mar '21

08 Mar '21

Hi, The Openstack Cinder driver support matrix (see link-1 below) lists the supported features for each storage and in the IBM Virtualize Family (SVC) section lacks support for 3 important features: Thin provisioning, Volume migration (storage assisted) and Active -Active high availability support. In the same site in section IBM Spectrum Virtualize volume driver (link-2 below), the functions described above seem to be supported and explained in more detail. Which of the two parts is true? Maybe the support matrix is out of date? best regards link-1 https://docs.openstack.org/cinder/latest/reference/support-matrix.html link-2 https://docs.openstack.org/cinder/latest/configuration/block-storage/driver…

2 1

[election][Octavia] PTL candidacy for Xena
by Gregory Thiemonge 08 Mar '21

08 Mar '21

Hi everyone, I would like to propose my candidacy for Octavia PTL during the Xena cycle. I have been an Octavia contributor for 2 years, and a core reviewer for 2 releases. Since then, I have been working in many areas in Octavia: adding support for new protocols (SCTP), fixing CI jobs, improving the octavia-dashboard. My focus will be to continue the work that the team has accomplished these last years, particularly adding many new features in Octavia (active/active load balancers, leveraging features provided by HAProxy 2.0) and improving our CI coverage (restoring CentOS jobs). Thanks for your consideration, Gregory

1 0

[neutron] Bug deputy report - week of March 1st
by Slawek Kaplonski 08 Mar '21

08 Mar '21

Hi, I was Neutron's bug deputy last week. Below is my summary. **critical** https://bugs.launchpad.net/neutron/+bug/1917487 - [FT] "IpNetnsCommand.add" command fails frequently - Assigned to Rodolfo https://bugs.launchpad.net/nova/+bug/1917610 - Migration and resize tests from tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest failing in neutron-tempest-dvr-ha-multinode-full - fix done in tempest https://review.opendev.org/c/openstack/tempest/+/778451 https://bugs.launchpad.net/neutron/+bug/1917793 - [HA] keepalived_state_change does not finish "handle_initial_state"execution - gate failure, assigned to Rodolfo **high** https://bugs.launchpad.net/neutron/+bug/1917409 - neutron-l3-agents won't become active - needs assignment https://bugs.launchpad.net/neutron/+bug/1917508 - Router create fails when router with same name already exists - related to ovn l3 plugin, needs assignment https://bugs.launchpad.net/neutron/+bug/1917370 - [functional] ovn maintenance worker isn't mocked in functional tests - **High** as it's causing gate failures or timeouts, assigned, patch: https://review.opendev.org/c/openstack/neutron/+/778080 - already merged https://bugs.launchpad.net/neutron/+bug/1917393 - [L3][Port forwarding] admin state DOWN/UP router will lose all pf-floating-ips and nat rules - assigned, In progress, Patch: https://review.opendev.org/c/openstack/neutron/+/778126 https://bugs.launchpad.net/neutron/+bug/1918108 - [OVN] IGMP snooping traps IGMP messages - assigned to Lucas already, **medium** https://bugs.launchpad.net/neutron/+bug/1917448 - GRE tunnels over IPv6 have wrong packet_type set in OVS - set as **Medium**, assigned, patch: https://review.opendev.org/c/openstack/neutron/+/778178, already merged **Wishlist** https://bugs.launchpad.net/neutron/+bug/1917437 - Enable querier for multicast (IGMP) in OVN, Assigned, In progress https://bugs.launchpad.net/neutron/+bug/1917866 - No need to fetch whole network object on port create - assigned to Oleg, patch proposed already https://review.opendev.org/c/openstack/neutron/+/778881 https://bugs.launchpad.net/neutron/+bug/1904559 - Designate driver: allow_reverse_dns_lookup doesn't works if dns_domain zone wasn't created - Switched to be RFE - please, especially drivers team members, check and triage it so we can discuss that on the drivers meeting, **undecided** https://bugs.launchpad.net/networking-ovn/+bug/1914857 - AttributeError: 'NoneType' object has no attribute 'db_find_rows' - Rodolfo and Lucas are triaging it, **Old bugs which needs attention** https://bugs.launchpad.net/neutron/+bug/1752903 - Floating IPs should not allocate IPv6 addresses - L3 subteam should take a look at it. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[election][neutron] PTL Candidacy for Xena
by Slawek Kaplonski 08 Mar '21

08 Mar '21

Hi, I want to propose my candidacy for Neutron PTL in the Xena cycle. Wallaby was my third cycle serving as Neutron PTL. I think I helped to keep the project in a healthy state and I would like to continue serving as the PTL and keep Neutron running well in the Xena cycle. In Wallaby we accomplished many important goals like e.g.: * finished migration to the engine facade, * improve our CI jobs and its overall stability, * and close of many feature parity gaps between OVN and OVS backends. But we also didn't finish some of the goals which were set for that cycle, like e.g. switching OVN to be the default Neutron backend in Devstack. If I will be elected, I would like to set it as my main goal for Xena cycle. We did a lot of work on adoption of the OVN backend in Neutron already and I think that we are now ready to move on and switch it to be the default backend in the Devstack. I want to focus on couple of things in the Xena cycle: * reduce our bug backlog as it is huge now, * maintenance and continue improvements of our CI, as this is "never ending story", * keep Neutron running in a smooth way. As I mentioned above, if I will be elected, Xena will be my 4th cycle as Neutron PTL and I would like to find some potential successors for the next cycles to help them onboard and understand what are the duties and responsibilities of the PTL. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] Inflated version dependency in os-brick
by Thomas Goirand 08 Mar '21

08 Mar '21

Hi, As I've started packaging Wallaby for Debian, I noticed that os-brick has very inflated version dependencies: $ diff -u ../requirements.txt requirements.txt --- ../requirements.txt 2021-03-08 10:54:44.896134101 +0100 +++ requirements.txt 2021-03-08 10:54:48.848127942 +0100 @@ -2,17 +2,16 @@ # of appearance. Changing the order has an impact on the overall integration # process, which may cause wedges in the gate later. -pbr!=2.1.0,>=5.4.1 # Apache-2.0 -eventlet>=0.25.1 # MIT -oslo.concurrency>=3.26.0 # Apache-2.0 -oslo.context>=2.23.0 # Apache-2.0 -oslo.log>=3.44.0 # Apache-2.0 -oslo.i18n>=3.24.0 # Apache-2.0 -oslo.privsep>=1.32.0 # Apache-2.0 -oslo.serialization>=2.29.0 # Apache-2.0 -oslo.service!=1.28.1,>=1.24.0 # Apache-2.0 -oslo.utils>=3.34.0 # Apache-2.0 -requests>=2.14.2 # Apache-2.0 -six>=1.10.0 # MIT -tenacity>=6.0.0 # Apache-2.0 -os-win>=3.0.0 # Apache-2.0 +pbr>=5.5.1 # Apache-2.0 +eventlet>=0.30.1 # MIT +oslo.concurrency>=4.4.0 # Apache-2.0 +oslo.context>=3.1.1 # Apache-2.0 +oslo.log>=4.4.0 # Apache-2.0 +oslo.i18n>=5.0.1 # Apache-2.0 +oslo.privsep>=2.4.0 # Apache-2.0 +oslo.serialization>=4.1.0 # Apache-2.0 +oslo.service>=2.5.0 # Apache-2.0 +oslo.utils>=4.8.0 # Apache-2.0 +requests>=2.25.1 # Apache-2.0 +tenacity>=6.3.1 # Apache-2.0 +os-win>=5.4.0 # Apache-2.0 Some of the above is clearly abusing. For example, I don't think Cinder really needs version 5.5.1 of PBR, and 5.5.0 should really be enough. I've traced it back to: https://review.opendev.org/c/openstack/os-brick/+/778807 If this is a consequence of the project stopping to test lower bounds of requirements, then this has gone really insane, and the bad practice must stop immediately to restore sanity, and we must revert. We're back 5 years ago where each projects was uselessly requiring the latest version of everything for no reason... From a downstream package maintainer perspective, this is a disaster move. Haven't we learned from our mistakes? Cheers, Thomas Goirand (zigo)

1 0

[infra][qe][nova] Would it be possible to host a custom cirros image somewhere for the nova-next job?
by Lee Yarwood 08 Mar '21

08 Mar '21

Hello all, I recently landed a fix in Cirros [1] to allow it to be used by the nova-next job when it is configured to use the q35 machine type [2], something that we would like to make the default sometime in the future. With no release of Cirros on the horizon I was wondering if I could instead host a build of the image somewhere for use solely by the nova-next job? If this isn't possible I'll go back to the Cirros folks upstream and ask for a release but given my change is the only one to land there in almost a year I wanted to ask about this approach first. Many thanks in advance, Lee [1] https://github.com/cirros-dev/cirros/pull/65 [2] https://review.opendev.org/c/openstack/nova/+/708701

4 9

Post to Openstack mail list
by DANILO PAOLO DELL'ORTO 08 Mar '21

08 Mar '21

Hi, I would like to post questions on the openstack mail lists, can you authorize me? best regards

1 0

[election][manila] PTL Candidacy for Xena
by Goutham Pacha Ravi 07 Mar '21

07 Mar '21

Greetings Zorillas & other Stackers, This is my candidacy to be the PTL for the OpenStack Manila team through the Xena cycle. I've had the great privilege of leading this unique team for the past three releases. During this time, we've had an enviable momentum and some fantastic achievements while building impactful software. I have enjoyed being a catalyst and an advocate for this motivated team, and I wish to do this a bit longer. In Wallaby, we harnessed our diverse strengths to mentor five new contributors through our student project internships, two of who were sponsored through Outreachy funding. They have all expressed their desire to become long term contributors. I am very proud of the manila team for their sincerity and enthusiasm in aiding new Stackers. I seek to further this outreach through the Xena release cycle. Testing and project quality will remain a top personal priority. The team was able to get new interop guidelines published last cycle, and we will focus on adding more test coverage under these guidelines, alongside addressing test gaps and innovating on more test scenarios. We have continued to implement the pro-active backport policy to get bug fixes back to stable branches and request timely releases of these stable branches. In the Xena cycle, I intend to codify this policy based on our learning and spread the release responsibility and know-how around the team. We split project maintenance into sub-teams during the Wallaby cycle, and recruited sub-team core reviewers. An increase in focus and velocity ensued across project code repositories. I intend to propose more additions to these sub-teams in the Xena cycle and encourage more contributors to take on project maintenance responsibilities. So, if you will have me, I wish to serve you through Xena and get things done. Thank you for your support, Goutham Pacha Ravi <gouthampravi(a)gmail.com> IRC: gouthamr

1 0

[horizon][i18n][infra] Renaming Chinese locales in Django from zh-cn/zh-tw to zh-hans/zh-hant
by Akihiro Motoki 07 Mar '21

07 Mar '21

Hi, The horizon team is planning to switch Chinese language codes in Django codes from zh-cn/zh-tw to zh-hans/zh-hant. Django, a framework used in horizon, recommends to use them since more than 5 years ago [1][2]. This change touches Chinese locales in the dashbaord codes of horizon and its plugins only. It does not change Chinese locales in other translations like documentations and non-Django python codes. This is to minimize the impact to other translations and the translation platform. ### What are/are not changed in repositories * horizon and horizon plugins * locales in the dashboard codes are renamed from zh-cn/zh-tw to zh-hans/zh-hant * locales in doc/ and releasenotes/ are not changed * other repositories * no locale change happens NOTE: * This leads to a situation that we have two different locales in horizon and plugin repositories (zh-hans/hant in the code folders and zh-cn/tw in doc and releasenotes folders), but it affects only developers and does not affect horizon consumers (operators/users) and translators. * In addition, documentations are translated in OpenStack-wide (not only in horizon and plugins). By keeping locales in docs, locales in documentation translations will be consistent. ### Impact on Zanata In Zanata (the translation platform), zh-cn/zh-tw continue to be used, so no change is visible to translators. The infra job proposes zh-cn/zh-tw GUI translatoins as zh-hans/zh-hant translations to horizon and plugin repositories. NOTE: The alternative is to create the corresponding language teams (zh-hans/zh-hant) in Zanata, but it affects Chinese translators a lot. They need to join two language teams to translate horizon (zh-hans/zh-hant) and docs (zh-cn/zh-tw). It makes translator workflow complicated. The proposed way has no impact on translators and they can continue the current translation process and translate both horizon and docs under a single language code. ### Changes in the infra scripts Converting Chinese locales of dashboard translations from zh-cn/zh-tw to zh-hans/zh-hant is handled by the periodic translation job. propose_translation_update job is responsible for this. [propose_translation_update.sh] * Move zh-cn/zh-tw translations related to Django codes in horizon and its plugins from zanata to zh-hans/hant directory. * This should happen in the master branch (+ future stable branhces such as stable/wallaby). ### Additional Remarks I18n SIG respects all language team coordinators & members, and is looking forward to seeing discussions and/or active contributions from the language teams. Currently all language codes follow the ISO 639-1 standard (language codes with relevant country codes), but the change introduces new language code forms like zh-hans/zh-hant. This follows IETF BCP 47 which recommends a combination of language codes and ISO 15924 script code (four letters). We now have two different language codes in OpenStack world. This is just to minimize the impact on the existing translations. It is not ideal. We are open for further discussion on language codes and translation support. ### References [1] https://code.djangoproject.com/ticket/18419 [2] https://www.djbook.ru/rel1.7/releases/1.7.html#language-codes-zh-cn-zh-tw-a… Thanks, Akihiro Motoki (irc: amotoki)

1 1

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-6 Update
by Ghanshyam Mann 07 Mar '21

07 Mar '21

Hello Everyone, Please find the week's R-6 updates on 'Migrate RBAC Policy Format from JSON to YAML' wallaby community-wide goals. Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress Summary: =============== Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml * Projects completed: 21 * Projects required to merge the patches: 8 * Projects required to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 16 Patches ready to merge: ================== * Octavia: https://review.opendev.org/c/openstack/octavia/+/764578 * Magnum: https://review.opendev.org/c/openstack/magnum/+/767242 * Murano: https://review.opendev.org/c/openstack/murano/+/768520 * Panko: https://review.opendev.org/c/openstack/panko/+/768498 * Solum: https://review.opendev.org/c/openstack/solum/+/768381 * Zaqar: https://review.opendev.org/c/openstack/zaqar/+/768488 Updates: ======= * Fixed the lower constraints failure for all the current open patches. * Few project patches are failing on config object initialization, I am debugging those and will fix them soon. * It is important to merge all the service side patches so that JSON format deprecation happens in the Wallaby release. -gmann

2 2

[neutron-dynamic-routing] Support for multiple BGP speaker
by Manu B 07 Mar '21

07 Mar '21

Hi, As understood from the code, currently the neutron dynamic routing supports only one BGP speaker per host *# os-ken can only support One *speaker if* self.cache.get_hosted_bgp_speakers_count() == 1: raise bgp_driver_exc.BgpSpeakerMaxScheduled(count=1) * Could you please let me know if this is due to some limitation of the os-ken driver? Or are there any other reasons for this limitation? Thanks, Manu

1 0

[Neutron][Nova][Ironic][Cinder][Keystone][Glance][Swift] OVN as the default network backend for DevStack
by Lucas Alvares Gomes 06 Mar '21

06 Mar '21

Hi all, As part of the Victoria PTG [0] the Neutron community agreed upon switching the default backend in Devstack to OVN. A lot of work has been done since, from porting the OVN devstack module to the DevStack tree, refactoring the DevStack module to install OVN from distro packages, implementing features to close the parity gap with ML2/OVS, fixing issues with tests and distros, etc... We are now very close to being able to make the switch and we've thought about sending this email to the broader community to raise awareness about this change as well as bring more attention to the patches that are current on review. Note that moving DevStack to ML2/OVN does not mean that ML2/OVS is discontinued and/or not supported anymore. The ML2/OVS driver is still going to be developed and maintained by the upstream Neutron community. Below is a e per project explanation with relevant links and issues of where we stand with this work right now: * Keystone: Everything should be good for Keystone, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/keystone/+/777963 * Glance: Everything should be good for Glace, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/glance/+/748390 * Swift: Everything should be good for Swift, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/swift/+/748403 * Ironic: Since chainloading iPXE by the OVN built-in DHCP server is work in progress, we've changed most of the Ironic jobs to explicitly enable ML2/OVS and everything is merged, so we should be good for Ironic too. Here is the test patch: https://review.opendev.org/c/openstack/ironic/+/748405 * Cinder: Cinder is almost complete. There's one test failure in the "tempest-slow-py3" job run on the "test_port_security_macspoofing_port" test. This failure is due to a bug in core OVN [1]. This bug has already been fixed upstream [2] and the fix has been backported down to the branch-20.03 [3] of the OVN project. However, since we install OVN from packages we are currently waiting for this fix to be included in the packages for Ubuntu Focal (it's based on OVN 20.03). I already contacted the package maintainer which has been very supportive of this work and will work on the package update, but he maintain a handful of backports in that package which is not yet included in OVN 20.03 upstream and he's now working with the core OVN community [4] to include it first in the branch and then create a new package for it. Hopefully this will happen soon. But for now we have a few options moving on with this issue: 1- Wait for the new package version 2- Mark the test as unstable until we get the new package version 3- Compile OVN from source instead of installing it from packages (OVN_BUILD_FROM_SOURCE=True in local.conf) What do you think about it ? Here is the test patch for Cinder: https://review.opendev.org/c/openstack/cinder/+/748227 * Nova: There are a few patches waiting for review for Nova, which are: 1- Adapting the live migration scripts to work with ML2/OVN: Basically the scripts were trying to stop the Neutron agent (q-agt) process which is not part of an ML2/OVN deployment. The patch changes the code to check if that system unit exists before trying to stop it. Patch: https://review.opendev.org/c/openstack/nova/+/776419 2- Explicitly set grenade job to ML2/OVS: This is a temporary change which can be removed one release cycle after we switch DevStack to ML2/OVN. Grenade will test updating from the release version to the master branch but, since the default of the released version is not ML2/OVN, upgrading from ML2/OVS to ML2/OVN as part of the grenade job is not supported. Patch: https://review.opendev.org/c/openstack/nova/+/776934 3- Explicitly set nova-next job to ML2/OVS: This job uses the QoS minimum bandwidth feature which is not yet supported by ML2/OVN [5][6] therefore we are temporarily enabling ML2/OVS for this job until that feature lands in core OVN. Patch: https://review.opendev.org/c/openstack/nova/+/776944 I also spoke briefly with Sean Mooney (irc: sean-k-mooney) about these changes and he suggested keeping all the Nova jobs on ML2/OVS for now because he feels like a change in the default network driver a few weeks prior to the upstream code freeze can be concerning. We do not know yet precisely when we are changing the default due to the current patches we need to get merged but, if this is a shared feeling among the Nova community I can work on enabling ML2/OVS on all jobs in Nova until we get a new release in OpenStack. Here's the test patch for Nova: https://review.opendev.org/c/openstack/nova/+/776945 * DevStack: And this is the final patch that will make this all happen: https://review.opendev.org/c/openstack/devstack/+/735097 It changes the default in DevStack from ML2/OVS to ML2/OVN. It's been a long and bumpy road to get to this point and I would like to say thanks to everyone involved so far and everyone that read the whole email, please let me know your thoughts. [0] https://etherpad.opendev.org/p/neutron-victoria-ptg [1] https://bugs.launchpad.net/tempest/+bug/1728886 [2] https://patchwork.ozlabs.org/project/openvswitch/patch/20200319122641.47377… [3] https://github.com/ovn-org/ovn/commit/0c26bc03064f2c21d208f0f860b48d8ab3938… [4] https://mail.openvswitch.org/pipermail/ovs-discuss/2021-February/050961.html [5] https://github.com/openstack/nova/blob/ded25f33c734ebff963f06984707a99fe76a… [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html Cheers, Lucas

8 16

[manila] Wallaby Collab Review - CephFS drivers updates (Mar 8th)
by Victoria Martínez de la Cruz 05 Mar '21

05 Mar '21

Hi everyone, Next Monday (March 8th) we will hold a Manila collaborative review session in which we'll go through the code and review the latest changes introduced in the CephFS drivers [0][1] This meeting is scheduled to last one hour, starting at 5.00pm UTC. It might extend a bit, but the most important should be covered within the hour. Meeting notes and relevant links are available in [2] Your feedback will be truly appreciated. Cheers, V [0] https://review.opendev.org/q/topic:%22bp%252Fupdate-cephfs-drivers%22+(stat… [1] https://review.opendev.org/q/topic:%22bp%252Fcreate-share-from-snapshot-cep… [2] https://etherpad.opendev.org/p/update-cephfs-drivers-collab-review

1 1

Re: [openstack-community] Keystone deprecated policies problem
by Amy 05 Mar '21

05 Mar '21

Adding the OpenStack discuss list. Thanks, Amy (spotz) > On Mar 5, 2021, at 3:19 PM, meberhardt(a)unl.edu.ar wrote: > > Hi, > > my installation complains about deprecated policies and throw errors when I try to run specific commands in cli as admin user(list projects or list users, for example). > > "You are not authorized to perform the requested action: identity:list_users." > > I tried to fix this by upgrading the keystone policies using oslopolicy-policy-generator and oslopolicy-policy-upgrade. Just found two places where I have those keystone policy files in my sistem: /etc/openstack_dashboard/keystone_policy.json and cd /lib/python3.6/site-packages/openstack_auth/tests/conf/keystone_policy.json > > I regenerated & upgraded it but Keystone still complains about the old polices. Where are it placed? How I shoud fix it? > > OS: CentOS 8 > Openstack version: Ussuri > Manual installation > > Thanks, > > Matias > > /* --------------------------------------------------------------- */ > /* Matías A. Eberhardt */ > /* */ > /* Centro de Telemática */ > /* Secretaría General */ > /* UNIVERSIDAD NACIONAL DEL LITORAL */ > /* Pje. Martínez 2652 - S3002AAB Santa Fe - Argentina */ > /* tel +54(342)455-4245 - FAX +54(342)457-1240 */ > /* --------------------------------------------------------------- */ > > > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community

1 0

[cinder] final patches for wallaby os-brick release need reviews
by Brian Rosmaita 05 Mar '21

05 Mar '21

Hello members of the cinder community: Please direct your attention to the following patches at your earliest convenience (i.e., right now): https://review.opendev.org/c/openstack/os-brick/+/777086 "NVMeOF connector driver connection information compatibility fix" - this fixes the regression in the nvmeof connector - patch has passed CI: Zuul, Mellanox SPDK (to detect the regression), and Kioxia (which uses the mdraid feature) - looks pretty much ready to go https://review.opendev.org/c/openstack/os-brick/+/778810 "Add release note for nvmeof connector" - the title says it all https://review.opendev.org/c/openstack/os-brick/+/778807 "Update requirements for wallaby release" - raises the minimum versions in the various requirements files to reflect what we're actually testing with right now - nothing major because of the adjustments made back in January to deal with the upgraded pip dependency resolver Happy reviewing! brian

2 2

[TripleO] Wallaby cycle highlights
by Marios Andreou 05 Mar '21

05 Mar '21

Hello all o/ Before you have a heart attack ;) Wallaby is still ~1 month away (and more like ~1.5 months+ for TripleO as we always trail the release) :) As mentioned in the last tripleo irc meeting [1] the deadline for wallaby cycle highlights is next Friday 12th March [2]. I had a go at and posted the proposal to https://review.opendev.org/c/openstack/releases/+/778971 . Please comment on the review or here if you want to update the wording and especially if I have forgotten to include something please accept my apologies if you let me know I can fix it :) thanks, marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-03-02-14.… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020714…

1 0

[glance] Doc about swift as backend
by Cristina Mayo Sarmiento 05 Mar '21

05 Mar '21

Hi everyone, Are there any specific documentation about how to configure Swift as backend of Glance service? I've found this: https://docs.openstack.org/glance/latest/configuration/configuring.html but I'm not sure what are the options I need. Firstly, I follow the installation guides of glance: https://docs.openstack.org/glance/latest/install/install-ubuntu.html and I have now file as store but I'rather change it. Thanks!

3 2

[release] Release countdown for week R-5 Mar 08 - Mar 12
by Herve Beraud 05 Mar '21

05 Mar '21

Development Focus ----------------- We are getting close to the end of the Wallaby cycle! Next week on 11 March 2021 is the Wallaby-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Xena cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on 11 March, 2021. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/wallaby branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… 11 March, 2021 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Cross-project events: - Wallaby-3 milestone (feature freeze): 11 March, 2021 (R-5 week) - RC1 deadline: 22 March, 2021 (R-3 week) - Final RC deadline: 5 April, 2021 (R-1 week) - Final Wallaby final release: 14 April, 2021 Project-specific events: - Cinder 3rd Party CI Compliance Checkpoint: 12 March, 2021 (R-5 week) -- 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

[kolla-ansible] partial upgrades / mixed releases in deployments
by Erik Panter 05 Mar '21

05 Mar '21

Hi, We are currently preparing to upgrade a kolla-ansible deployed OpenStack cluster and were wondering if it is possible to upgrade individual services independently of each other, for example to upgrade one service at a time to Ussuri while still using kolla-ansible to deploy and reconfigure the Train versions of the other services. Our idea was that either the Ussuri release of kolla-ansible is used to deploy Train and Ussuri services (with properly migrated configuration), or that two different releases and configurations are used for the two sets of services in the same deployment. Does anyone have experience if this is practical or even possible? Thank you in advance, Erik _____ Erik Panter Systementwickler | Infrastruktur Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp Tel.: 05772 / 293-900 Fax: 05772 / 293-333 Mobil: 0151 / 12345678 e.panter(a)mittwald.de https://www.mittwald.de Geschäftsführer: Robert Meyer, Florian Jürgens St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.

2 1

Need help to get rally test suite
by Ankit Goel 04 Mar '21

04 Mar '21

Hello Experts, Need some help on rally. I have installed Openstack rally on centos. Now I need to run some benchmarking test suite. I need to know is there any pre-existing test suite which covers majority of test cases for Openstack control plane. So that I can just run that test suite. I remember earlier we use to get the samples under rally/samples/tasks/scenarios for each component but now I am not seeing it but I am seeing some dummy files. So from where I can get those samples json/yaml files which is required to run the rally tests. Awaiting for your response. Thanks in Advance Regards, Ankit Goel

3 3

[qa][election][ptl] PTL non-candidacy
by Masayuki Igawa 04 Mar '21

04 Mar '21

Hello all, I will not be running again for the QA PTL for the Xena cycle because I believe rotating leadership for open source projects is a good thing basically, and I will also have very limited bandwidth for the cycle. Therefore it would be best if someone else runs for QA PTL for the cycle. But I'll be around and continue to involve in OpenStack though it'll be downstream mostly. So, feel free to ping me if you want. Best Regards, -- Masayuki Igawa

1 0

[kolla][kolla-ansible] distro mixing on hosts
by Eric K. Miller 04 Mar '21

04 Mar '21

Hi, We have been pretty consistent in deploying CentOS 7 on physical hardware where Kolla Ansible deploys its containers. However, we're going to be switching to Debian 10.8. It looks like Kolla Ansible likely won't care which distro is installed on the physical hardware, and so some nodes could have CentOS 7 and others have Debian 10.8. Long-term, we'll replace the CentOS 7 machines with Debian 10.8 and re-deploy. Kolla Container images will still be CentOS 7, but we will be recreating Kolla images with Debian and deploying those long term too. Is this supported? Any obvious issues we should be aware of? We will have the same interface names, so we will be pretty consistent in terms of the environment - but wanted to see if there was any gotchas that we didn't think of. Also, I guess I should ask if there are any specific Debian 10.8 issues we should be aware of? Has anybody else done this? :) Thanks! Eric

2 2

[TripleO][Validation] Validation CLI simplification
by Mathieu Bultel 04 Mar '21

04 Mar '21

Hi TripleO Folks, I'm raising this topic to the ML because it appears we have some divergence regarding some design around the way the Validations should be used with and without TripleO and I wanted to have a larger audience, in particular PTL and core thoughts around this topic. The current situation is: We have an openstack tripleo validator set of sub commands to handle Validation (run, list ...). The CLI validation is taking several parameters as an entry point and in particular the stack/plan, Openstack authentication and static inventory file. By asking the stack/plan name, the CLI is trying to verify and understand if the plan or the stack is valid, if the Overcloud exists somewhere in the cloud before passing that to the tripleo-ansible-inventory script and trying to generate a static inventory file in regard to what --plan or stack has been passed. The code is mainly here: [1]. This behavior implies several constraints: * Validation CLI needs Openstack authentication in order to do those checks * It introduces some complexity in the Validation code part: querying Heat to get the plan name to be sure the name provided is correct, get the status of the stack... In case of Standalone deployment, it adds more complexity then. * This code is only valid for "standard" deployments and usage meaning it doesn't work for Standalone, for some Upgrade and FFU stages and needs to be bypassed for pre-undercloud deployment. * We hit several blockers around this part of code. My proposal is the following: Since we are thinking of the future of Validation and we want something more robust, stronger, simpler, usable and efficient, I propose to get rid of the plan/stack and authentication functionalities in the Validation code, and only ask for a valid inventory provided by the user. I propose as well to create a new entry point in the TripleO CLI to generate a static inventory such as: openstack tripleo inventory generate --output-file my-inv.yaml and then: openstack tripleo validator run --validation my-validation --inventory my-inv.yaml By doing that, I think we gain a lot in simplification, it's more robust, and Validation will only do what it aims for: wrapp Ansible execution to provide better logging information and history. The main concerns about this approach is that the user will have to provide a valid inventory to the Validation CLI. I understand the point of view of getting something fully autonomous, and the way of just kicking *one* command and the Validation can be *magically* executed against your cloud, but I think the less complex the Validation code is, the more robust, stable and usable it will be. Deferring a specific entry point for the inventory, which is a key part of post deployment action, seems something more clear and robust as well. This part of code could be shared and used for any other usages instead of calling the inventory script stored into tripleo-validations. It could then use the tripleo-common inventory library directly with tripleoclient, instead of calling from client -> tripleo-validations/scripts -> query tripleo-common inventory library. I know it changes a little bit the usage (adding one command line in the execution process for getting a valid inventory) but it's going in a less buggy and racy direction. And the inventory should be generated only once, or at least at any big major cloud change. So, I'm glad to get your thoughts on that topic and your overall views around this topic. Thanks, Mathieu [1] https://github.com/openstack/tripleo-validations/blob/master/tripleo_valida…

3 3

[neutron] Drivers meeting 05.03.2021 cancelled
by Slawek Kaplonski 04 Mar '21

04 Mar '21

Hi, Due to lack of agenda let's cancel tomorrow's drivers meeting. Have a great weekend and see You on the meeting next week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Consultation] SFC issue
by Jhen-Hao Yu 04 Mar '21

04 Mar '21

Dear Sir, We are testing a simple SFC in OpenStack (Stein) + OpenDaylight (Neon) + Open vSwitch (v2.11.1). It's an all-in-one deployment. We have read the document: https://readthedocs.org/projects/odl-sfc/downloads/pdf/latest/ and https://github.com/opnfv/sfc/blob/master/docs/release/scenarios/os-odl-sfc-… [image: image.png] Our SFC topology: [image: enter image description here] <https://i.stack.imgur.com/7QMWh.png> All on the same compute node. Build SFC through API: 1. openstack sfc flow classifier create --source-ip-prefix 10.20.0.0/24 --logical-source-port p0 FC1 2. openstack sfc port pair create --description "Firewall SF instance 1" --ingress p1 --egress p1 --service-function-parameters correlation=None PP1 3. openstack sfc port pair group create --port-pair PP1 PPG1 4. openstack sfc port chain create --port-pair-group PPG1 --flow-classifier FC1 --chain-parameters correlation=nsh PC1 Ping from client to server, but packet did not pass through firewall，open vswitch log show: [image: enter image description here] <https://i.stack.imgur.com/eucDz.png> Flow table: [image: enter image description here] <https://i.stack.imgur.com/cx3rJ.jpg> trace flow: [image: enter image description here] <https://i.stack.imgur.com/Jhi8M.png> Is there something wrong with the OpenStack instructions? It seems SFC proxy not work or there may be some bugs in "networking-sfc"? Thanks! Sincerely, Jhen-Hao >From NTU CSIE [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> 03/04/21, 05:26:34 PM

1 0

[election][release] Hervé Beraud candidacy for Release Management PTL for Xena
by Herve Beraud 04 Mar '21

04 Mar '21

(nomination posted to https://review.opendev.org/c/openstack/election/+/778623) Hello, I would like to continue serving as PTL for Release Management during the Xena cycle. Wallaby was my first PTL experience and it allowed me to deeply improve my knowledge about Openstack. I'd like to continue to work on growing the core team to constitute experienced team members to whom we could pass the torch. Anything we can do to help anyone to join the team and know what to do and how to do it will be better for us all. We have a lot of our processes mostly automated, but we also have few unfinished business from the Wallaby cycle. So as a PTL I have the intention to make the team focus on finishing these work. It has been an interesting, active and rewarding release cycle, and I am excited to continue learning and applying those lessons to keep things moving and looking for any ways I can add to the already great body of work we have in our release. I will be happy to do it if you give me the opportunity. Thanks for your consideration, Hervé -- 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

[election][TripleO] PTL candidacy for Xena
by Marios Andreou 03 Mar '21

03 Mar '21

(nomination posted to https://review.opendev.org/c/openstack/election/+/778500) Hello I would like to continue serving as PTL for TripleO during the Xena cycle. Wallaby was my first PTL experience and it has been challenging and rewarding. I've learnt a lot about release processes and other repo related admin (like moving projects to the Independent release cycle). As I said in the W candidacy nomination [1], nowadays TripleO works in self-contained squads that drive technical decisions. We've had a lot of work across these squads (as always) during W with progress in a number of areas including moving port/network creation outside of Heat (ports v2), tripleo-ceph/tripleo-ceph-client and switching out ceph-ansible for cephadm, removing swift and the deployment plan, BGP support with frrouter and using ephemeral Heat for the overcloud deployment. I'd like to continue what i started in W, which is, to increase socialisation across tripleo squads and try to reign in the multitude of repos that we have created (and some now abandoned) over the years. After a well attended Wallaby PTG we have reinstated our traditional IRC meetings in #tripleo. I've started to "tidy up" our repos, moving some of the older and no longer used projects to 'independent' (os-refresh-config and friends, tripleo-ipsec) and started the process to mark older branches as EOL, starting with Rocky. There is a lot more to do here and I will be happy to do it if you give me the opportunity, thanks for your consideration, marios [1] https://opendev.org/openstack/election/raw/branch/master/candidates/wallaby…

1 0

Puppet openstack modules
by Bessghaier, Narjes 03 Mar '21

03 Mar '21

Dear OpenStack team, My name is Narjes and I'm a PhD student at the University of Montréal, Canada. My current work consists of analyzing code reviews on the puppet modules. I would like to precisely know what the ruby files are used for in the puppet modules. As mentioned in the official website, most of unit test are written in ruby. Are ruby files destined to carry out units tests or destined for production code. I appreciate your help, Thank you

3 4

[election][nova] PTL Candidacy for Wallaby
by Balazs Gibizer 03 Mar '21

03 Mar '21

Hi, I would like to continue serving as the Nova PTL in the Xena cycle. In Wallaby I hope I helped to keep Nova alive and kicking and I intend to continue what I have started. My employer is supportive to continue spending time on PTL and core duties. If I am elected then I will try to focus on the following areas: * Keeping the Nova bug backlog under control * Working on changes that help the maintainability and stability of Nova * Finishing up things that are already ongoing before starting new items Also, I'd like to note that if elected then Xena will be my 3rd consecutive term as Nova PTL so I will spend some time during the cycle to find my successor for the Y cycle. Cheers, gibi

1 0

Train/SR-IOV direct port mode live-migration - question
by Heib, Mohammad (Nokia - IL/Kfar Sava) 03 Mar '21

03 Mar '21

Hi All, we recently moved to openstack Train and according to the version release notes the SR-IOV direct port live-migration support was added to this version. so we tried to do some live-migration to vm with two SR-IOV direct ports attached to bond interface on the vm (no vSwitch interface or a indirect only direct ports) but seems that we have an issue with maintaining the network connectivity during and after the live-migration, according to [1] i see that in order to maintain network connectivity during the migration we have to add one indirect or vswitch port to the bond and this interface will carry the traffic during the migration and once the migration completed the direct port will back to be the primary slave on the target VM bond. my question is if we don't add the indirect port we will lose the connectivity during the migration which makes sense to me, but why the connectivity does not back after the migration completed successfully, and why the bond master boot up with no slaves on the target VM? according to some documents and blueprints that I found in google (including [2],[3]) the guest os will receive a virtual hotplug add even and the bond master will enslave those devices and connectivity will back which is not the case here. so I wondering maybe I need to add some scripts to handle those events (if so where to add them) or some network flags to the ifcfg-* files or i need to use a specific guest os? [1] : https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi… <https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi…> [2] :https://www.researchgate.net/publication/228722278_Live_migration_with_pass-through_device_for_Linux_VM <https://www.researchgate.net/publication/228722278_Live_migration_with_pass…> [3] :https://openstack.nimeyo.com/72653/openstack-nova-neutron-live-migration-with-direct-passthru <https://openstack.nimeyo.com/72653/openstack-nova-neutron-live-migration-wi…> *bond master ifcfg file:* DEVICE=bond1 BONDING_OPTS=mode=active-backup HOTPLUG=yes TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none NAME=bond1 ONBOOT=yes *slaves ifcfg files:* TYPE=Ethernet DEVICE=eth0 HOTPLUG=no ONBOOT=no MASTER=bond1 SLAVE=yes BOOTPROTO=none NM_CONTROLLED=no *guest OS:* CentOS Linux release 7.7.1908 (Core) * * */Thanks in advance for any help :)/,*

2 1

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

anti-affinity: what're the mechanics?
by Ken D'Ambrosio 03 Mar '21

03 Mar '21

Hey, all. Turns out we really need anti-affinity running on our (very freaking old -- Juno) clouds. I'm trying to find docs that describe its functionality, and am failing. If I enable it, and (say) have 10 hypervisors, and 12 VMs to fire off, what happens when VM #11 goes to fire? Does it fail, or does the scheduler just continue to at least *try* to maintain as few possible on each hypervisor? Thanks! -Ken

3 2