May 2020 - openstack-discuss - lists.openstack.org

[neutron][QoS] IRC meeting cancelled on May 5
by Rodolfo Alonso 05 May '20

05 May '20

Hello: Due to the lack of agenda, I'm going to cancel the Neutron QoS meeting today. Regards. Rodolfo Alonso (ralonsoh)

1 0

[all][PTL][TC] PTG Signup Last Call
by Kendall Nelson 05 May '20

05 May '20

Hello! In an effort to get a schedule set and posted on the website and so that you can all block your calendars for the event, we ask that *teams finish signing up for time by Sunday, May 10th at 7:00 UTC*. We have done some consolidation to save room resources (as we will have to set up/pay for rooms ahead of time) so if you are in the list below, please note that your room may have changed, but the timing should be the same. Also note, some teams may be set to switch rooms throughout the week. Currently Signed Up Teams: Airship Automation SIG Cinder Edge Computing Group First Contact SIG Interop WG Ironic Glance Heat Horizon Kata Containers Kolla Manila Monasca Multi-Arch SIG Neutron Nova Octavia OpenDev OpenStackAnsible OpenStackAnsibleModules OpenStack-Helm Oslo QA Scientific SIG Security SIG Tacker TripleO Thanks! -The Kendalls(diablo_rojo & wendallkaters)

1 0

[all] Virtual PTG Registration Live
by Kendall Waters 04 May '20

04 May '20

Hey everyone, Registration for the June 2020 Virtual PTG is now live! It is free but its still extremely important that you register as this is primarily so we have a way to contact attendees with information about the event as we figure the rest of the details out. So please take a minute to register: https://virtualptgjune2020.eventbrite.com <https://virtualptgjune2020.eventbrite.com/> Let us know if you have any questions! -the Kendalls (diablo_rojo & wendallkaters)

1 0

cross distro Virtual PTG planning
by Thomas Goirand 04 May '20

04 May '20

Dear package maintainers, We used to have a cross-distro discussion during each PTG (well, summits, since I didn't attend any PTG since the split). I was wondering if people from other distros would be interested in having such a session again. Please tell if you hare as a follow-up here, then maybe we can add ourselves in the ethercalc. I used to know everyone, like Haikel, people from SuSE, etc. Nowadays, I only know people from Canonical. I'd love to meet the new guys around. Cheers, Thomas Goirand (zigo)

3 2

[cinder] critical bugs/patches for RC-2
by Brian Rosmaita 03 May '20

03 May '20

The proposed list is here: https://etherpad.opendev.org/p/cinder-ussuri-rc-backport-potential Please prioritize your reviewing accordingly. There are several proposed but not approved bugs on the list; I could use some feedback on whether they are release-critical or not. Please reply on the etherpad. thanks, brian

1 2

[blazar] IRC meeting cancelled on May 5
by Pierre Riteau 03 May '20

03 May '20

Hello, Due to a scheduling conflict, I will not be able to chair the Blazar IRC meeting on Tuesday May 5. I propose to cancel and meet as usual on May 12. Best wishes, Pierre Riteau (priteau)

1 0

[InteropWG] Draft Guidelines for 2020.06 Ussuri core and addons for orchestration and dns
by prakash RAMCHANDRAN 03 May '20

03 May '20

Hi all, We have been trying to draft Ussuri guidelines API for Market logo mark as part of InteropWGIn case anyone is interested in reviewing the draft patch please feel free to comment with +1 only.The +2's are reserved for Mark-Voelker & Egle.sigler c Vice Chair and past Vice-Chairs for Interop WGCall for Review: https://review.opendev.org/722137 We are investing add-ons for OpenStack Edge , Containers and Swift backends.If you have any suggestions please pitch in. Please add your ideas to PTG etherpad link in the follwoing (Jine 1st - 1st 2 hour slot)https://etherpad.opendev.org/p/interop ThnaksPrakash https://etherpad.opendev.org/p/ecg_virtual_ptg_planning_june_2020

2 1

[goals][Drop Python 2.7 Support] Status Report: COMPLETED \o/
by Ghanshyam Mann 02 May '20

02 May '20

Hello Everyone, Please find the final status for the py2.7 drop goal. Finally, it is COMPLETED!! With this (after three continuous cycles), I am taking a break from community goals (at least for V cycle :))!!. Wiki page is updated: https://wiki.openstack.org/wiki/Python3 I have added the 'Python3 Only' column here https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projec… Completion Report: =============== * Swift & Storlets are the two projects keeping py2.7 support. * All projects have completed the goal and now are python3-only. * It has been another roller coaster :) and I appreciate everyone helped in this work and all the projects reviewing the patches on time with few exceptions :). * A Lot of gate issues occurred and fixed during this transition especially making branchless tooling testing the mixed python version ( stable branch on py2 and other on py3). * I finished the audit for all the projects. requirement repo will be cleaning up the py2 caps in Victoria cycle[1]. Some ongoing work on deployement projects repo or unmaintained repo: ------------------------------------------------------------------------------------------- These are dpendendant on other work for testing framework etc. This can be continued and need not to be tracked under this goal. * python-barbicanclient: https://review.opendev.org/#/c/699096/ ** This repo seems unmaintained for last 6 months and the gate is already broken. * Openstack Charms - Most of them merged, few are waiting for the team to migrate to Python3 Zaza functional test framework. * Openstackansible - This will finish once centos jobs will be migrated to Centos8. * Openstack-Helm - No conclusion yet from help team on what else to do for py2 drop. -gmann

6 6

[all][qa] Gate Status: week 20-18
by Ghanshyam Mann 02 May '20

02 May '20

Hello Everyone, I am highlighting the few of the gate issues we fixed or in-progress recently. 1. Ubuntu xenial node jobs on stable stein onwards gate or 3rd party CI. Tempest 23.0.0 is the last version supported for py2.7 or py3.5. And we used the that version to tests stable/rocky jobs(py3.5 env) gate and any py2.7 job on stein or train gate. It was fixed on many projects when gate started failing with master Tempest. Last week when Tempest new version 24.0.0 is released and the same is updated in master upper-constraint, we found xenial node job running on stein gate (for Octavia and Ironic at least). Fixing those is not easy which needs overriding the constraint for that particular job. Octavia and Ironic removed the xenial job which is the right step. But few 3rd party CI not migrated to Bionic stein onwards will stop working now. One workaround can be to override the constraint to stable/rocky via env var UPPER_CONSTRAINTS_FILE but I have not tried if that works or not. If not, moving your CI to Bionic is the way forward. I am trying a new approach to cap the constraint in tox.ini itself whenever a new Tempest version is released. That can avoid hacking the same via UPPER_CONSTRAINTS_FILE. For example, Tempest 24.0.0 tag's tox.ini use stable/ussuri constraint. 2. Bug#1876330. devstack-plugin-ceph-tempest-py3 failing for rescue BFV instance test New tests added for rescue BFV instance feature on Nova failed on ceph job. lyarwood is working on the bug but for now, we have taken the step forward to skip the tests for ceph. Any new tests which do not work on ceph, we need to add the tests in ceph blacklist file until the bug is fixed. Job is green now. if it was failing on your gate where it is running as voting, please recheck. - https://review.opendev.org/#/c/724866/ I have also proposed to make ceph job as voting on the Tempest side (it was n-v till now) so that we can take these steps well before merging the new tests on the Tempest gate. - https://review.opendev.org/#/c/724948/1 -gmann

1 0

[all] A call for consolidation and simplification
by Thierry Carrez 01 May '20

01 May '20

Hi all, I'd like to issue a call for consolidation and simplification for OpenStack development. In the early years of the project, we faced a lot of challenges. We had to spread the development load across manageable-size groups, so we encouraged the creation of a lot of project teams. We wanted to capture all the energy that was sent towards the project, so we passed project structure reforms (like the big tent) that would aggressively include new community groups in the "official" OpenStack community. We needed to remove bottlenecks, so we encouraged decentralized decision making. And we had to answer unique challenges, so we created software to match them (Zuul). In summary, we had a lot of people, and not enough systems to organize them, so we created those. Fast-forward to 2020, and our challenges are different. The many systems that we created in the early days have created silos, with very small groups of people working in isolation, making cross-project work more difficult than it should be. The many systems that we created generate a lot of fragmentation. Like we have too many meetings (76, in case you were wondering), too much energy spent running them, too much frustration when nobody joins. Finally, the many systems that we created represent a lot of complexity for newcomers to handle. We have 180 IRC channels, most of them ghost towns where by the time someone answers, the person asking the question is long gone. So I think it's time to generally think about simplifying and consolidating things. It's not as easy as it sounds. Our successful decentralization efforts make it difficult to make the centralized decision to regroup. It's hard to justify time and energy spent to /remove/ things, especially those that we spent time creating in the first place. But we now have too many systems and not enough people, so we need to consolidate and simplify. Back around Havana, when we had around the same number of active contributors as today, we used to have 36 meetings and 20 teams. Do we really need 180 IRC channels, 76 meetings, 63 project teams (not even counting SIGs)? Yes, we all specialized over time, so it's hard to merge for example Oslo + Requirements, or QA + Infrastructure, or Stable + Release Management, or Monasca + Telemetry. We are all overextended so it's hard to learn new tricks or codebases. And yet, while I'm not really sure what the best approach is, I think it's necessary. Comments, thoughts? -- Thierry Carrez (ttx)

9 16