March 2022 - openstack-discuss - lists.openstack.org

[cinder] PTG Planning Etherpad
by Rajat Dhasmana 03 Mar '22

03 Mar '22

Hello Argonauts, As you might be aware that the Zed PTG is approaching so I've created an etherpad for the details of the PTG and adding topics. To summarize, PTG will take place from 4-8 April, 2022 and below are the details for Cinder PTG: Date: 5-8 April, 2022 TIme: 1300-1700 UTC Connection info will be shared prior to the meeting on the etherpad and the cinder channel on IRC. Most probably it will be on BlueJeans (as has been in the past) but suggestions are welcome. Etherpad: https://etherpad.opendev.org/p/zed-ptg-cinder-planning Regarding the timings, as discussed in the cinder meeting twice, the attendees had no concern and it is the preferred time for the PTG since past 3 virtual PTGs. If there are any concerns, do let me know and we can also schedule your topic as convenient for your timezone. Lastly, I would encourage everyone to add topics as soon as they can since it makes the planning/arranging of topics easier and better. Thanks and regards Rajat Dhasmana

1 0

[all][tc] Technical Committee next weekly meeting on Mar 4th at 1500 UTC
by Ghanshyam Mann 03 Mar '22

03 Mar '22

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

1 2

[election][heat][ptl] PTL non-candidacy
by Rico Lin 03 Mar '22

03 Mar '22

Hi all, As the PTL election will soon start, I would like to share my statement on not planning to run another term of Heat PTL. And Instead, I encourage anyone (core reviewer or not) who is interested to put their name on. I will definitely still stay around and help with reviews and patches. cheers, *Rico Lin*

4 3

[QA][OpenStackSDK][release] Cycle With Intermediary without recent deliverables
by Előd Illés 02 Mar '22

02 Mar '22

Hi, Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest Yoga release available on release week. The following deliverables have done a Yoga release, but it was not refreshed in the last two months: tempest patrole (this was not yet released at all in Yoga) python-openstackclient (I remember that openstacksdk cannot do another release in Yoga due to issues on master branch. Is this also valid for python-openstackclient?) You should consider making a new one very soon, so that we don't use an outdated version for the final release. Előd Illés irc: elodilles

2 1

[ironic] Zed PTG etherpad
by Iury Gregory 02 Mar '22

02 Mar '22

Hello ironicers! I've created an etherpad to collect topics for our Zed PTG [1] Feel free to add any topics on it =) Later tomorrow I will be sharing the ideas for possible PTG slots and in the upstream meeting on Monday (March 7) we will announce. [1] https://etherpad.opendev.org/p/ironic-zed-ptg -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[designate] Zed PTG planning etherpad
by Michael Johnson 02 Mar '22

02 Mar '22

Hi Designate community, In preparation for our PTG sessions in April I have created an etherpad for us to add topics for discussion. https://etherpad.opendev.org/p/zed-ptg-designate Please add your attendance and topics. Michael

1 0

[tripleo] Dynamically generating firewall rules for the haproxy host on behalf of a deployed service
by Brent Eagles 02 Mar '22

02 Mar '22

Hi all, Designate has a requirement that appears to be a first for TripleO. It needs to deploy miniDNS instances on the internal network but each are accessible from the public network so external bind instances can sync with them. This is done by mapping port numbers on the VIP to each miniDNS instances [1] e.g. 10.0.0.5:16000 --> 172.16.2.184:5354 10.0.0.5:16001 --> 172.16.2.185:5354 10.0.0.5:16002 --> 172.16.2.186:5354 . . . <for each controller> The haproxy configuration is relatively straightforward [2]. There would be no problem if it the haproxy puppet managed the firewall rules, but for typical deployments we appear to disable this [3] and rely on the tripleo.firewall ansible module instead. The complicating factors are: a. the ports range depends on the number of miniDNS instances. b. the miniDNS deployment needs to set firewall rules wherever haproxy happens to live as they are not guaranteed to be on the same host. AFAICT, our ansible based firewall rule mechanism doesn't allow for setting firewall rules on hosts in addition to the ones that the service is being deployed on. Possible solutions I've been considering: a. Have haproxy puppet create firewall rules on the public API network and use tripleo.firewall for everything else. I think we generally don't distinguish which networks firewall rules are applicable to so this would be an "interesting", pervasive change. This is in PID 1's wheelhouse and I'd be interested in how they feel about this. b. Somehow create a jinja-ed firewall rule for haproxy that gets processed at deploy time so details could be filled in using cloud information. This seems like it would be kind of fragile, may not even be possible and depends on details of the framework I'm not familiar with. c. Extend tripleo.firewall or tripleo.iptables to process jinja'd rules - but that's problematic because it needs to be set on the haproxy host, and miniDNS is elsewhere. d. Create some ansible that gets run in the haproxy hosts that generates the firewall rules based on cloud info. I feel this is a bit ugly. Does anyone have any suggestions on other solutions or thoughts on the above? Cheers, Brent 1. https://bugzilla.redhat.com/show_bug.cgi?id=1897319 The TripleO HAProxy instance needs to be configured for BIND->miniDNS AXFR 2. https://review.opendev.org/c/openstack/puppet-tripleo/+/828169 Designate: create proxy ports on external VIP to access miniDNS workers. 3. https://bugs.launchpad.net/tripleo/+bug/1961799 haproxy template tasks to apply IPTables rules are no ops. -- Brent Eagles Principal Software Engineer Red Hat Inc.

3 2

[largescale-sig] Next meeting: Mar 2nd, 15utc
by Thierry Carrez 02 Mar '22

02 Mar '22

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220302T15 Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[cinder] Bug deputy report for week of 03-02-2022
by Sofia Enriquez 02 Mar '22

02 Mar '22

This is a bug report from 02-23-2022 to 03-02-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Low - https://bugs.launchpad.net/cinder/+bug/1962221 "[lightos] Compression handling in lightos driver while default compression enabled." Fix proposed to master. Incomplete - https://bugs.launchpad.net/cinder/+bug/1962607 "IndexError when creating Backups." Fix proposed to master. Cheers -- 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

[TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
by Marios Andreou 02 Mar '22

02 Mar '22

Hello TripleO o/ During the last period the tripleo-ci team has been working on getting tripleo CI jobs to run centos-9. On master branches across all TripleO repos we now run C9 exclusively (since [1]). On Wallaby branches, after the work at [2] (in particular after https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we will run both C8 and C9 jobs. I started an etherpad at [3] thinking this would be a PTG topic, but I think we'll want to have this conversation way before then. There is a tripleo-heat-templates example in the etherpad that shows what we can expect from the job runs (note the exact jobs that run will vary per repo and even between changes depending on the files touched - but generally there will be duplication between 8 and 9 jobs). The current proposal is that we keep a minimal subset on C8 Wallaby, with C9 wallaby having the full set of jobs. Two factors that will affect our decisions are (there may be more?) i) Upgrades requirements - are we supporting upgrading to Wallaby on 8? For example, the coming undercloud-upgrade-ffu job will be train 8 to wallaby 8. In which case we definitely need to keep at least some subset of 8 jobs (and can't entertain the removal of 8 from Wallaby completely). ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8 but this will soon switch. For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone (no scenarios? some subset of them?), undercloud-ffu, minor update. This is just to start the conversation so please reply if you have thoughts or comments about any of the above. We are planning to discuss this in the coming tripleo-ci community call this coming Tuesday at 1330 UTC - meeting link at [4] so please join us if you can and would like to participate, regards, marios [1] https://review.opendev.org/q/topic:c8_teardown_master [2] https://review.opendev.org/q/topic:c9_wallaby_gates [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9 [4] https://meet.google.com/bqx-xwht-wky

4 7