April 2020 - openstack-discuss - lists.openstack.org

[tripleo] Proposing Sergii Golovatiuk and Jesse Petorius for tripleo-upgrade core
by Jose Luis Franco Arza 06 May '20

06 May '20

Hi, I would like to propose to Sergii Golovatiuk and Jesse Pretorius as core members for the tripleo-upgrade <https://github.com/openstack/tripleo-upgrade>repository. This repository is being used mostly to automate the workflow to upgrade, update and fast-forward TripleO. And it is being used in our CI automation, downstream and upstream. Both, Sergii <https://review.opendev.org/#/q/project:openstack/tripleo-upgrade+owner:%22S…> and Jesse <https://review.opendev.org/#/q/project:openstack/tripleo-upgrade+owner:%22J…>, have been very active in the repository with patches and reviews. And they have a good understanding of the code, as well as its integration with tripleo-quickstart and infrared. Please, feel free to add your votes into the thread. Thanks, José Luis

11 13

[TripleO][train][rdo] installation of undercloud fails during Run container-puppet tasks step1
by Ruslanas Gžibovskis 06 May '20

06 May '20

Hi all, I am running a fresh install of rdo train, on centos7 I almost a week I am facing error at this step: TASK [Run container-puppet tasks (generate config) during step 1] So I have ansible.log attached, I cannot find anything, where it is failing. According to some understanding in ansible, it fails if it finds stderr output. I cannot find error/fail or smth, I see Notices and Warnings, but I believe it is not stderr? I see containers running and removed after some time. (as it should be I think)... Could you help me, where to dig? -- Ruslanas Gžibovskis +370 6030 7030

5 19

[openstack-ansible] dropping suse support
by Mohammed Naser 05 May '20

05 May '20

Hi everyone, I've been trying to avoid writing this email for the longest time ever. It's really painful to have to reach this state, but I think we've hit a point where we can no longer maintain support for SUSE within OpenStack Ansible. Unfortunately, with the recent layoffs, the OSA team has taken a huge hit in terms of contributors which means that there is far less contributors within the project. This means that we have less resources to go around and it forces us to focus on a more functional, reliable and well tested set of scenarios. Over the past few cycles, there has been effort to add SUSE support to OpenStack Ansible, during the time that we had maintainers, it was great and SUSE issues were being fixed promptly. In addition, due to the larger team at the time, we found ourselves having some extra time where we can help unbreak other gates. Jesse used to call this a "labour of love", which I admired at the time and hoped we continue to do as much as we can of. However, the lack of a committed maintainer for OpenSUSE has resulted in constantly failing jobs[1][2] (which were moved to non-voting, wasting CI resources as no one fixed them). In addition, it's causing several gate blocks for a few times with no one really finding the time to clean them up. We are resource constrained at this point and we need the resource to go towards making the small subset of supported features functional (i.e. CentOS/Ubuntu). We struggle with that enough, and there seems to be no deployers that are running SUSE in real life at the moment based on bugs submitted. With that, I propose that we drop SUSE support this cycle. If anyone would like to volunteer to maintain it, we can review that option, but that would require a serious commitment as we've had maintainers step off and it hurts the velocity of the project as no one can merge code anymore. ..Really wish I didn't have to write this email Mohammed [1]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct… [2]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…

6 9

[blazar] Updating blazar-core and blazar-release groups
by Pierre Riteau 05 May '20

05 May '20

Hello, I noticed in a recent blazar-specs patch [1] that lots of historical contributors were requested as reviewers. I assume this is because the blazar-core group was used (this is not a feature that I've used before on Gerrit). To avoid spamming people who haven't worked on Blazar for years, I propose to remove the following members of the blazar-core group: Dina Belova Hiroaki Kobayashi Nikolay Starodubtsev Pablo Andres Fuente Ryota MIBU Swann Croiset Sylvain Bauza I would also remove Hiroaki Kobayashi from the blazar-release group. Please let me know if you have any objections. [1] https://review.opendev.org/#/c/723115/

2 2

[ironic][ptg] Virtual PTG - Victoria
by Iury Gregory 05 May '20

05 May '20

Hello Ironicers! We need to choose the slots for the Virtual PTG[1] on the official schedule [2]. So, if you are interested in participating you need to do two things: 1- Add your name and topics to the etherpad [3]. 2- Fill out the doodle in [4]. Thank you! [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/Ironic-VictoriaPTG-Planning [4] https://doodle.com/poll/mbpr2x7z3t5hqec6 -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 2

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

[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

[tripleo] CI
by Wesley Hayutin 01 May '20

01 May '20

Greetings, Status update... Master: GREEN Stable Branches impacted by: https://bugs.launchpad.net/tripleo/+bug/1875890 fixed Now we are trying to promote each branch to level out pacemaker on the node and containers. Queens is promoting now. Train: GREEN Queens: RED ( current priority ) In addition to the pacemaker issue which has resolved in our periodic testing jobs, we're hitting issues w/ instances timing out in tempest https://bugs.launchpad.net/tripleo/+bug/1876087 Stein: RED Also seems to have the same issue as Queens https://bugs.launchpad.net/tripleo/+bug/1876087 ( under investigation for Stein ) Rocky: RED Also seems to have the same issue as Queens https://bugs.launchpad.net/tripleo/+bug/1876087 ( under investigation for Rocky ) I will be promoting Rocky to level out pacemaker next. In order to get the voting jobs in queens back to green, I'm disabling tempest on containers-multinode. https://review.opendev.org/#/c/724703/ Additional notes may be found: https://hackmd.io/1pY-KQB_QwOe-a-5oEXTRg

2 2

[manila][stable] Additions and Removals from stable-core
by Goutham Pacha Ravi 01 May '20

01 May '20

Hello Stackers, I'd like to add a couple of maintainers to manila-stable-maint: https://review.opendev.org/#/admin/groups/1099,members - dviroel (Douglas Viroel) - silvacarlos (Carlos Eduardo) Both Douglas and Carlos understand the stable branch policy [1] and adhere to it. Thanks! Goutham [1] https://docs.openstack.org/project-team-guide/stable-branches.html

4 5