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

[stein][neutron] gratuitous arp
by Ignazio Cassano 13 May '21

13 May '21

Hello, I have a problem on stein neutron. When a vm migrate from one node to another I cannot ping it for several minutes. If in the vm I put a script that ping the gateway continously, the live migration works fine and I can ping it. Why this happens ? I read something about gratuitous arp. Please, help me ? Any workaround , please ? Best Regards Ignazio

3 33

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

[ceilometer][octavia] polling meters
by Ionut Biru 14 Jul '20

14 Jul '20

Hello guys, I was trying to add in polling.yaml and pipeline from ceilometer the following: - network.services.lb.active.connections - network.services.lb.health_monitor - network.services.lb.incoming.bytes - network.services.lb.listener - network.services.lb.loadbalancer - network.services.lb.member - network.services.lb.outgoing.bytes - network.services.lb.pool - network.services.lb.total.connections But it doesn't work, I think they are for the old lbs that were supported in neutron. I found https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollst… but this is not available in stein or train. I was wondering if there is a way to meter loadbalancers from octavia. I mostly want for start to just meter if a loadbalancer was deployed and has status active. -- Ionut Biru - https://fleio.com

3 17

[tc][election] campaign discussion: how TC can solve the less contributor issue?
by Ghanshyam Mann 22 Jun '20

22 Jun '20

This topic is a very important and critical area to solve in the OpenStack community. I personally feel and keep raising this issue wherever I get the opportunity. To develop or maintain any software, the very first thing we need is to have enough developer resources. Without enough developers (either open or closed source), none of the software can survive. OpenStack current situation on contributors is not the same as it was few years back. Almost every project is facing the less contributor issue as compare to requirements and incoming requests. Few projects already dead or going to be if we do not solve the less contributors issue now. I know, TC is not directly responsible to solve this issue but we should do something or at least find the way who can solve this. What do you think about what role TC can play to solve this? What platform or entity can be used by TC to raise this issue? or any new crazy Idea? -gmann

14 26

[tc][uc][all] Starting community-wide goals ideas for V series
by Ghanshyam Mann 15 Jun '20

15 Jun '20

Hello everyone, We are in R14 week of Ussuri cycle which means It's time to start the discussions about community-wide goals ideas for the V series. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. We have the Zuulv3 migration goal already accepted and pre-selected for v cycle. If you are interested in proposing a goal, please write down the idea on this etherpad[2] - https://etherpad.openstack.org/p/YVR-v-series-goals Accordingly, we will start the separate ML discussion over each goal idea. Also, you can refer to the backlogs of community-wide goals from this[3] and ussuri cycle goals[4]. NOTE: TC has defined the goal process schedule[5] to streamlined the process and ready with goals for projects to plan/implement at the start of the cycle. I am hoping to start that schedule for W cycle goals. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/YVR-v-series-goals [3] https://etherpad.openstack.org/p/community-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals [5] https://governance.openstack.org/tc/goals/#goal-selection-schedule -gmann

10 22

[nova][ptg] virtual PTG
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, I need to book slots for nova discussions on the official schedule[2] of the virtual PTG[1]. I need two things to do that: 1) What topics we have that needs real-time discussion. Please add those to the etherpad [3] 2) Who wants to join such real-time discussion and what time slots works for you. Please fill the doodle[4] Based on the current etherpad content we need 2-3 slots for nova discussion and a half slot for cross project (current neutron) discussion. Please try to provide your topics and options before the Thursday's nova meeting. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/nova-victoria-ptg [4] https://doodle.com/poll/ermn3vxy9v53aayy

1 5

[cinder] [ironic] Any update on Cinder Ceph ISCSI Driver?
by kevinz 02 Jun '20

02 Jun '20

Hi Cinder, We are looking forward to the IRONIC boot from Cinder Ceph Volume. I went through the mailist and found the conversation last year, the main gap for the Ironic boot from Cinder volume(Ceph BACKEND) is lacking Cinder Ceph iscsi driver. http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006041.html So I'm sending to ask the current status for this. We are from Linaro, all our machines are under Ironic and we use Ceph as backend storage. Recently we are looking at the Diskless server boot plan from the Ceph cluster. Any info or update or advice, I really appreciate it. Look forward to hearing from you.

3 4

[tripleo] Deprecating Paunch in Ussuri
by Emilien Macchi 28 May '20

28 May '20

Hi folks, In Ussuri we manage to successfully replace Paunch by Ansible (role + modules) to manage the container lifecycle in TripleO. As a reminder, this effort was part of the Simplification work that is being done in TripleO to reduce our number of tools and align it with our deployment framework based on Ansible. https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_contai… Paunch has been turned off for some time now and isn't tested anymore in upstream CI (master only). I would like to propose its deprecation in Ussuri and a removal in Victoria (or later if any valid pushback). https://review.opendev.org/#/c/720598/ Thanks, -- Emilien Macchi

2 3

[all] [kolla] Kolla Builder - next generation
by Radosław Piliszek 28 May '20

28 May '20

Hello fellow OpenStackers and Kollars (or Koalas) in particular, today is the day when I finally sit down to write up my thoughts on Kolla, and I mean *Kolla*, the container image building project for OpenStack and friends, nothing more (nor less). *** Some background on Kolla to get everyone on the same page (or close enough): Kolla builds images for production use. Kolla is upstream for TripleO containers and Kolla-Ansible deployment. These are container images, think OCI and Docker in particular since Kolla actually relies on Dockerfile format to specify build recipes and Docker runs building (TripleO runs buildah on the same recipes). Kolla supports three distributions as bases: CentOS (TripleO does override this for RHEL as well), Debian and Ubuntu. In the interim periods Kolla supports two distribution releases to ease/smooth the transition process for operators (like currently CentOS 7 and 8 in Train, while Ussuri is 8 only). What is more, each distro has two flavours (or 'types' as they are called for now): binary and source. This 'type' applies only to OpenStack software. Binary means that Kolla uses downstream packages (rpm/deb) while source means to use pip and install from official tarballs (or repos if it is master) and PyPI for deps, utilising venv to keep it separate from distro stuff. Finally, there is particular target architecture: x86_64, aarch64 and ppc64le. All of above affect the support matrix which is based on 3 or 4 dimensions (distro, flavour, arch and sometimes distro version). [1] Kolla offers a high level of customisability via various overrides levels. See docs for details [2] Kolla engine offers hierarchical approach to image building, under the assumption that more than one image is often deployed on the same machine so layer sharing is beneficial. Kolla helps collect sources for OpenStack projects to build desired versions of them. All recipes are templated using Jinja2 syntax. Images contain both run-time and, mostly in the case of 'source' flavour, build-time tools and libraries. *** That's it for the background. :-) So where is the problem you might ask? Oh, there are plenty. The general is that Kolla has lots of logic in templates. Thankfully, Kolla has macros for most stuff but still Jinja2 limitations make it hard to document exceptions (no inline comments in arrays anyone?). We lose visibility into real dependency graphs and may be easily reinstalling same stuff, any optimisations are limited and would require parsing of both Jinja2 and Dockerfile syntax. In general the current approach is ugly and becomes unwieldy (e.g. getting warnings about empty continuation lines). There is layering hell: dependency on long &&ed commands which are templated out to avoid useless layers. Support matrix is great for an overview. There is a hidden layer to it though, different combinations may support different features. This is not documented so far and not so easy to follow from sources. This stems from the fact that different extra components have different availability in distros, but this is not easily apparent from sources. Also, there is no way to turn feature on/off. You might do an override, but then again, which to keep, which not to? Which is which? Oh! Finally, the images tend to be heavy due to inclusion of build-time deps. *** That's it for issues (hopefully!) My idea is to reuse Kolla engine where it shines: sources collection, system of plugins, hierarchical building; but replace the part that smells - Jinja2 templating. Giving up on Jinja2 might encompass giving up on Dockerfile syntax, but that is optional and depends on what makes it more amenable to avoid further pitfalls. With giving up on Jinja2, the idea is to generate building recipes fully programmatically from Python. It would be possible to introduce "Features" - sets of packages to install based on the (distro, arch) tuple. This would result in more flexibility - turning them on/off (some could be optional, some not). There could be more than one optimization strategy regarding when packages get installed: you want only standalone blah-blah? Then Kolla won't be installing XYZ and ABC just because ugma-ugma and tickle-tickle require them and you "could save some space" (TM). In the same vein, features could declare which components are build-time and which are run-time and this would make it straightforward to separate the sides. The above effort could well be coordinated with different projects to reuse bindep contents. So far Kolla does not use bindep because it often installs too much and not enough at the same time. Do note it would still be bindep-less for external services. There would still need to exist a general mechanism for providing custom command executions required by some images. For contributors and cores this new approach would bring more sanity as to the scope of proposed changes. Also, it would be possible to get quick insight into feature support and autogenerate docs for that as well. Similarly, current concept of unbuildable images would no longer be required because unbuildability would be dictated by lack of support for a required feature. *** Looking forward to your opinions/thoughts. *** [1] https://docs.openstack.org/kolla/train/support_matrix.html [2] https://docs.openstack.org/kolla/train/admin/image-building.html -yoctozepto

5 9

[tripleo][operators] Removal of mistral from the TripleO Undercloud
by Kevin Carter 26 May '20

26 May '20

Hello stackers, In the pursuit to remove Mistral from the TripleO undercloud, we've discovered an old capability that we need to figure out how best to handle. Currently, we provide the ability for an end-user (operator / deployer) to pass in "N" Mistral workflows as part of a given deployment plan which is processed by python-tripleoclient at runtime [0][1]. From what we have documented, and what we can find within the code-base, we're not using this feature by default. That said, we do not remove something if it is valuable in the field without an adequate replacement. The ability to run arbitrary Mistral workflows at deployment time was first created in 2017 [2] and while present all this time, its documented [3] and intra-code-base uses are still limited to samples [4]. As it stands now, we're on track to making Mistral inert this cycle and if our progress holds over the next couple of weeks the capability to run arbitrary Mistral workflows will be the only thing left within our codebase that relies on Mistral running on the Undercloud. So the question is what do we do with functionality. Do we remove this ability out right, do we convert the example workflow [5] into a stand-alone Ansible playbook and change the workflow runner to an arbitrary playbook runner, or do we simply leave everything as-is and deprecate it to be removed within the next two releases? Although it would be perfectly acceptable to keep Mistral around a little while longer, it would also be a bummer if this one capability was the only reason we were not able to remove Mistral from the Undercloud. Any and all feedback from operators, deployers, developers, former developers, etc would be greatly appreciated. Thank you in advance. [0] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [1] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [2] https://review.opendev.org/#/c/457874 [3] https://specs.openstack.org/openstack/tripleo-specs/specs/pike/tripleo-deri… [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/48da6a13936… [5] https://opendev.org/openstack/tripleo-common/src/commit/cc4f9c57b708259e9e9… Kevin Carter IRC: kecarter

5 9

[swift] Rolling upgrade, any version relationships?
by Mark Kirkwood 24 May '20

24 May '20

Hi, we are looking at upgrading our 2.7.0 Swift cluster. In the past I've modeled this on a dev system by upgrading storage nodes one by one (using 2.17 as the target version). This seemed to work well - I deliberately left the cluster half upgraded for an extended period to test for any cross version weirdness (didn't see any). However I'm wanting to check that I have not missed something important. So my questions are: - If upgrading from 2.7.0 is it safe to just grab the latest version (e.g 2.23)? - If not is there a preferred version to jump to first? - Is it ok for the upgrade to take extended time (e.g weeks) and therefore be running with some new and some old storage nodes for that time? regards Mark

3 5

[swift] Erasure code hardware offloading
by Mark Kirkwood 22 May '20

22 May '20

Hi, Can Swift make use of an Erasure Code offload card (e.g https://community.mellanox.com/s/article/understanding-erasure-coding-offlo… regards Mark

2 1

[tc][tricircle] Retiring the Tricircle project
by Ghanshyam Mann 18 May '20

18 May '20

Hello Everyone, As you know, Tricirlce is a leaderless project for the Victoria cycle means there is no PTL candidate for Victoria cycle. 'No PTL' is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping project from OpenStack Governance[1]. TC discussed the Tricircle project in today's meeting[2] and checked if the project has maintainers but no PTL or it is missing the maintainer completely. By looking at the Ussuri cycle development work, it seems no activity related to Tricircle except few gate fixes or community goal commits[2]. Based on all these checks, we are going to start the process of removing Tricircle from governance in the Victoria cycle as specified in the Mandatory Repository Retirement resolution [4] and detailed in the infra manual [5]. NOTE: release team is trying to do Ussuri release for Tricircle's deliverables if we can get this reno fix merge - https://review.opendev.org/#/c/721697/ >From the Victoria cycle, Tricircle will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to all Tricircle contributors and PTLs for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-04-21-15.01.log.html [3] https://www.stackalytics.com/?metric=commits&release=ussuri&module=tricircl… [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [5] https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#retiring-… -gmann

1 1

[swift] Adding disks - one by one or all lightly weighted?
by Mark Kirkwood 14 May '20

14 May '20

Hi, We are wanting to increase the number of disks in each of our storage nodes - from 4 to 12. I'm wondering whether it is better to: 1/ Add 1st new disk (with a reduced weight)...increase the weight until full, then repeat for next disk etc 2/ Add 'em all with a (much i.e 1/8 of that in 1/ ) reduced weight...increase the weights until done Thoughts? regards Mark

2 2

[oslo][nova][vmware] Replacement for suds library
by Stephen Finucane 14 May '20

14 May '20

The suds-jurko library used by oslo.vmware is emitting the following warnings in nova tests. /nova/.tox/py36/lib/python3.6/site-packages/suds/resolver.py:89: DeprecationWarning: invalid escape sequence \% self.splitp = re.compile('({.+})*[^\%s]+' % ps[0]) /nova/.tox/py36/lib/python3.6/site-packages/suds/wsdl.py:619: DeprecationWarning: invalid escape sequence \s body.parts = re.split('[\s,]', parts) These warnings are going to be errors in Python 3.10 [1]. We have over 18 months before we need to worry about this [2], but I'd like to see some movement on this well before then. It seems the suds-jurko fork is dead [3] and movement on yet another fork, suds-community, is slow [4]. How difficult would it be to switch over to something that does seem maintained like zeep [5] and, assuming it's doable, is anyone from VMWare/SAP able to do this work? Stephen [1] https://docs.python.org/3.9/whatsnew/3.9.html#you-should-check-for-deprecat… [2] https://www.python.org/dev/peps/pep-0596/ [3] https://bitbucket.org/jurko/suds/src/default/ [4] https://github.com/suds-community/suds/pull/32 [5] https://python-zeep.readthedocs.io/en/master/

5 6

[Tempest][Restack]Call for help on 2020:06 Certificaion
by prakash RAMCHANDRAN 08 May '20

08 May '20

Hi all, Appreciate all your inputs in mail and one-on-one conversations I had with few of you. Like to set proper expectations before we deal with extending our goals. First we must deliver on continuity of Refstack, while we evaluate the value it adds to end users through survey. I. Every Release - There is a new criterion for Certification - Do we have one for 2020.06? - Who has volunteered or would like to volunteer for this effort? II. Can we have previous WG Chair or anyone can brief us (by call or by email ) as what the process was and how it was managed. |||. Who were last release OSF Reviewers? Can they volunteer for 2020:06 release definition for Refstack - https://opendev.org/openstack/refstack/ VI. Given the circumstances (CoViD-19) will it be possible to deliver Refstack in June /July 2020? (Need some estimates from TC or others who managed this in past years) V. Is Zun - ?, Magnum -? Are both OCI and/or CNI compliant? - Can they be tested using Tempest and add those two or any other container projects to refstack core? For Survey (suggest any specifics Questions to ask- may be few questions to - Customer / Vendors/ new feedback Q1-Value of Certification , Q2. How Often customers ask for it in RFP or sales cycle?, Q3. What additional Tests, process, frequency etc will add value for them?Q4. Do you think we should continue the efforts of Refstack?) Let me know through email and have added this to TC meeting for Thursday April 2.https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting ThanksPrakash Sent from Yahoo Mail on Android

2 1

[keystone] Core group changes
by Colleen Murphy 07 May '20

07 May '20

Hi team, I'm very pleased to say that Vishakha Agarwal has joined the python-keystoneclient core team! Vishakha has gained a lot of knowledge of the clients in the last few months and this change will help empower her to continue to drive our goals of ensuring all of the clients fully support keystone's APIs. Thanks for taking this on, Vishakha! I also must announce that I've removed Dave Chen from the core list. Dave's responsibilities at his company have not been related to keystone for some time, and although we've been very grateful for the occasional review he gives from time to time, he's let me know he believes it's time to be formally removed. As with every core removal, if life brings him back to keystone we'll gladly welcome him back to the core team. Thanks, Dave, for all your hard work on keystone! Colleen

4 3

[Syntribos] Does anyone still use this?
by Gage Hugo 07 May '20

07 May '20

The Security SIG has recently been looking into updating several sites/documentation and one part we discussed the last couple meetings was the security tools listings[0]. One of the projects listed there, Syntribos, doesn't appear to have much activity[1] outside of zuul/python/docs maintenance and the idea of retiring the project was mentioned. However, there does seem to be an occasional bug-fix submitted, so we are sending this email out to see if anyone is still utilizing Syntribos. If so, please either respond here, reach out to us in the #openstack-security irc channel, or fill out the section in the Security SIG Agenda etherpad[2]. Thanks! [0] https://security.openstack.org/#security-tool-development [1] https://review.opendev.org/#/q/project:openstack/syntribos [2] https://etherpad.openstack.org/p/security-agenda

2 2

[infra][qa][sigs][tc] Forming a Testing and Collaboration Tools (TaCT) SIG
by Jeremy Stanley 07 May '20

07 May '20

The Infrastructure team, and the CI team before it, has traditionally existed to care for the continuous integration and collaboration infrastructure on which the OpenStack community relies. With the rise of the OpenDev Collaboratory as a distinct effort outside of (but still primarily in service of) OpenStack, the majority of the team's former systems administration activities are no longer occurring under the authority of OpenStack. Most of the software and configuration management repositories previously in the care of the Infra team are also no longer official OpenStack deliverables, and have become part of OpenDev as well (and their biggest development effort, Zuul+Nodepool, was already spun out as an independent Open Infrastructure Project last year). With the above responsibilities moved elsewhere, the existence of a formal team is less of a necessity. What remains is a need to support OpenStack's project-specific testing and collaboration tooling and services, primarily job configuration and other things which shouldn't currently be generalized into components of the OpenDev Collaboratory. To this end, I propose the creation of a new Testing and Collaboration Tools (TaCT) SIG which would serve the role currently occupied by the OpenStack Infrastructure team. I'm open to alternative names, but employing the vague term "infrastructure" has perpetually confused newcomers to our community, so this seems like an opportunity for something less overloaded. The TaCT SIG would consist of the usual suspects: people who review OpenStack job configuration changes, people who dig into problems with test frameworks to unblock the integrated gate queue, people who figure out strange Python packaging related issues, people who help work out lapsed control of Launchpad admin groups... also, ideally, the person selected by the TC to serve as OpenStack's representative on the OpenDev Advisory Council would be heavily involved. Many of these activities are closely related to work the Quality Assurance team is doing, so hopefully folks who are active in QA will also participate in this SIG. What do you think? Does this satisfactorily capture the infrastructure needs of the OpenStack community, and could it serve as an alternative to the current Infrastructure team? -- Jeremy Stanley

5 7

[ironic] II SPUC - The Sanity Preservation Un-Conference
by Iury Gregory 07 May '20

07 May '20

Hello everyone \o/ We are going for the second edition of SPUC! For those who doesn't know what is SPUC check [0]. There is only 3 things you need to do: 1) Fill out the doodle in [1] *, it has options for the next two weeks since May 1st is a holiday. 2) Brainstorm some ideas of things you might want to talk about/present or LEARN! * 3) Dust off your silly hats! * * From Julia's email =) [0] Thank you! [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013521.ht… [1] https://doodle.com/poll/2q5zmv3g6uy2475e -- *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>*

3 3

[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