March 2021 - openstack-discuss - lists.openstack.org

[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 05 Mar '21

05 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 05 Mar '21

05 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