March 2020 - openstack-discuss - lists.openstack.org

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

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

16 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

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

27 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 25 May '20

25 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 23 May '20

23 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

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

15 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 09 May '20

09 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

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

08 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

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

06 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

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

02 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

[manila][ptg] Victoria Cycle PTG in Vancouver - Planning
by Goutham Pacha Ravi 01 May '20

01 May '20

Hello Zorillas and other interested Stackers, We've requested space to gather at the Open Infrastructure PTG event in Vancouver, BC between June 8th-11th 2020. This event gives us the opportunity to catch up in person (and via telepresence) and discuss the next set of goals for manila and its ecosystem of projects. As has been the norm, there's now a planning etherpad for us to collect topics and vote upon [1]. Depending on how much space/time we are budgeted, we will select and schedule these topics. Please take a look and add your topics to the etherpad. Thanks, Goutham [1] https://etherpad.openstack.org/p/vancouver-ptg-manila-planning

1 1

Virtual OpenDev Update
by Ashlee Ferguson 23 Apr '20

23 Apr '20

Hi everyone, As we continue to gather feedback and discuss what a virtual OpenDev will look like, we wanted to provide you with an update around the event. While we are still attempting to solve some of the riddles of virtual event world, we did come up with some decisions that give us something to build on, which are based on input and experience from members of the Programming Committee. Decisions: - OpenDev will happen after the Virtual PTG (exact format and timing TBD) - Will not be simultaneous/parallel Tracks so everyone has the opportunity to participate in more than one - 3 Tracks, each on different date: - Hardware Automation - Large Scale Ops - Containers in Production We also discussed the original intent and goals of OpenDev to make sure we’re still heading in a direction that’s beneficial for the community, especially since it will no longer directly precede the upcoming PTG. Similar to past OpenDev events, the goal is to identify the questions we don’t have the answers for, and to use that time to dive in and determine the work ahead of us, working together, sharing use cases, and learning from other people asking those same questions. High-level decisions, goals, and some areas we’re looking for feedback are in the etherpad below. As you continue to experience this new amazing world of virtual events, please add any feedback or ideas to the etherpad below. We’re looking forward to creating virtual OpenDev with you all! https://etherpad.openstack.org/p/Virtual_OpenDev_Planning <https://etherpad.openstack.org/p/Virtual_OpenDev_Planning> Ashlee Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 2

Re: [nova][cinder][ops] question/confirmation of legacy vol attachment migration
by Brett Milford 22 Apr '20

22 Apr '20

On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor <geguileo(a)redhat.com> wrote: > > On 06/12, Brett Milford wrote: > > On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann <mriedemos(a)gmail.com> wrote: > > > > > > On 10/17/2019 5:24 AM, Gorka Eguileor wrote: > > > > I stand by my initial recommendation, being able to update the existing > > > > attachment to add the connection information from Nova. > > > > > > OK, thanks for the input and thoughtfulness on this. I've abandoned my > > > change since I'm not going to be pushing this boulder anymore but left > > > notes in the change in case someone else wants to pick it up some day. > > > > > > Note to nova cores: this means we'll have legacy volume attachment > > > compat code around forever. > > > > > > -- > > > > > > Thanks, > > > > > > Matt > > > > > > > Hi Groka, Cinder & Nova devs, > > > > Following up this thread from the context of > > https://review.opendev.org/#/c/579004/ > > > > To summarise the discussion: > > - initialize_connection shouldn't be called more than once, as it > > may mess up some drivers. > > - To (safely) refresh connection_info a new api for cinder is required. > > Hi, > > It may be a new API or a modification of one of the existing ones. > > > > - a patch to nova, such as #579004 could make a call to this new api > > to refresh connection info on events such as reboot. > > > > Is there any other context to this issue I've missed or an alternate > > path to solving this? > > > > Does the creation of a new api for cinder have any implications for > > being able to backport this patch for nova? > > > > I don't think backporting it in Nova would do us much good, since the > Cinder code would not be backportable (it's a new feature, not a bug > fix). > > > > What would be the process for me to kick off this work? > > > > You should propose a Cinder spec [1] for your work and you may provide a > WIP patch to Cinder at the same time, though depending on the review you > may have to completely change that code later. > > Cheers, > Gorka. > > [1]: https://opendev.org/openstack/cinder-specs > > > Thanks for your help, > > Brett (bcm) > > -- > > ❯ brett > > > Cheers Matt, Groka, I thought this might be the case. -- ❯ brett

2 2

[election][nova] PTL Candidacy for Victoria
by Balázs Gibizer 18 Apr '20

18 Apr '20

Hi, I'd like to announce my candidacy for Nova PTL for Train. I'm a long time Nova contributor and Nova core since 2017. I'm currently serving as temporary Nova PTL since we lost Eric during the Ussuri cycle. We are facing multiple challenges for Victoria. We have to organize the first fully virtual PTG to plan the Victoria cycle due to sever travel restrictions around the word. I have already proposed ways [1] to the Nova team and I will continue working on making the best out of the current situation. In the past months we have lost Matt and Eric, two key contributors and Nova maintainers. So I will work on regrowing the Nova core team to restore our review bandwidth. As a first step I proposed two new Nova core members [2][3]. But I will also look for more possible candidates and I will try to mentor them to further increase the size of the core team. We have many unfinished business from the Ussuri cycle. So as a PTL I have the intention to make the team focus on finishing these work before we start any new big change in Nova. Thanks, Balazs Gibizer (gibi) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013555.ht… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013511.ht… [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013519.ht…

3 2

OpenStack should be buildable with sphinx 2.4: FTBFS in many packages
by Thomas Goirand 16 Apr '20

16 Apr '20

Hi, Sphinx 2.4 has been uploaded to Experimental. I just received bug reports against the OpenStack packages because some of them cannot be built with Sphinx 2.4. Here's the list: - ironic - os-api-ref - aodh - cloudkitty - kombu - panko - ceilometerclient - ceilometermiddleware - doc8 - dracclient - glareclient - murano-pkg-check - os-xenapi - scciclient - sahara - sphinxcontrib-programoutput - tempest-horizon It'd be nice if those affected could be fixed for Ussuri. IMO, it's just the doc, so fixing it wouldn't hurt code quality. In other words: help would be more than welcome writing patch or reviewing them, and testing Sphinx 2.4 compatibility. Cheers, Thomas Goirand (zigo)

7 13

[cinder][ops][extended-maintenance-sig][public-cloud-sig][enterprise-wg] Cinder to EOL some branches
by Brian Rosmaita 13 Apr '20

13 Apr '20

This is a courtesy notice that having received no responses to my email of 28 October [0] proposing to EOL some currently open Cinder branches, and following the policy articulated in [1], at today's Virtual PTG meeting the Cinder project team has decided to put the following stable branches into the End of Life state: driverfixes/mitaka driverfixes/newton stable/ocata stable/pike I will submit the paperwork to get this process moving one week from today (2 December 2019). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

4 8

[octavia] dropping support for stable/queens
by Adam Harwell 11 Apr '20

11 Apr '20

I'm officially proposing dropping support for the queens stable branch of Octavia. Given a quorum of cores, we will move forward with marking it EOL and all that entails. Thanks, --Adam

5 5

[all][PTL][release] Call for Ussuri Cycle Highlights
by Kendall Nelson 09 Apr '20

09 Apr '20

Hello Everyone! Its time to start thinking about calling out 'cycle-highlights' in your deliverables! As PTLs, you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it makes them easy to reference because they get compiled into a pretty website like this from the last few releases: Rocky[1], Stein[2], Train[3]. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. Looking through your release notes might be a good place to start. *The deadline for cycle highlights is the end of the R-5 week [4] on April 10th.* How To Reminder: ------------------------- Simply add them to the deliverables/train/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/train/highlights.html file or the output of the build-openstack-sphinx-docs job under html/train/ highlights.html. Can't wait to see you all have accomplished this release! Thanks :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/rocky/highlights.html [2] https://releases.openstack.org/stein/highlights.html [3] https://releases.openstack.org/train/highlights.html [4] htt <https://releases.openstack.org/train/schedule.html#t-cycle-highlights> https://releases.openstack.org/ussuri/schedule.html

2 5

[nova][gate] status of some gate bugs
by melanie witt 08 Apr '20

08 Apr '20

Hey all, We've been having a tough time lately in the gate hitting various bugs while our patches go through CI. I just wanted to mention a few of them that I've seen often in my gerrit notifications and give a brief status on fix efforts. * http://status.openstack.org/elastic-recheck/#1813789 This one is where the nova-live-migration job fails a server evacuate test with: "Timeout waiting for [('network-vif-plugged', 'e3d3db3f-bce4-4889-b161-4b73648f79be')] for instance with vm_state error and task_state rebuild_spawning.: eventlet.timeout.Timeout: 300 seconds" in the screen-n-cpu.txt log. lyarwood has a WIP patch here: https://review.opendev.org/713674 and sean-k-mooney has a WIP patch here: https://review.opendev.org/713342 * https://launchpad.net/bugs/1867380 This one is where the nova-live-migration or nova-grenade-multinode job fail due to n-cpu restarting slowly after being reconfigured for ceph. The server will fail to build and it's because the test begins before nova-compute has fully come up and we see this error: "Instance spawn was interrupted before instance_claim, setting instance to ERROR state {{(pid=3783) _error_out_instances_whose_build_was_interrupted" in the screen-n-cpu.txt log. lyarwood has a patch approved here that we've been rechecking the heck out of that has yet to merge: https://review.opendev.org/713035 * https://launchpad.net/bugs/1844568 This one is where a job fails with: "Body: b'{"conflictingRequest": {"code": 409, "message": "Multiple possible networks found, use a Network ID to be more specific."}}'" gmann has a patch proposed to fix some of these here: https://review.opendev.org/711049 There might be more test classes that need create_default_network = True. * http://status.openstack.org/elastic-recheck/#1844929 This one is where a job fails and the following error is seen one of the logs, usually screen-n-sch.txt: "Timed out waiting for response from cell 8acfb79b-2e40-4e1c-bc3d-d404dac6db90". The TL;DR on this one is there's no immediate clue why it's happening. This bug used to hit more occasionally on "slow" nodes like nodes from the OVH or INAP providers (and OVH restricts disk iops [1]). Now, it seems like it's hitting much more often (still mostly on OVH nodes). I've been looking at it for about a week now and I've been using a DNM patch to add debug logging, look at dstat --disk-wait output, try mysqld my.cnf settings, etc: https://review.opendev.org/701478 So far, what I find is that when we get into the fail state, we get no rows back from the database server when we query for nova 'services' and 'compute_nodes' records, and we fail with the "Timed out waiting for response" error. Haven't figured out why yet, so far. The disk wait doesn't look high when this happens (or at any time during a run) so it's not seeming like it's related to disk IO. I'm continuing to look into it. Cheers, -melanie [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010505…

5 8

[k8s][zun] Introduce a new feature in Ussuri - CRI integration
by Hongbin Lu 08 Apr '20

08 Apr '20

Hi all, As we are approaching the end of Ussuri cycle, I would like to take a chance to introduce a new feature the Zun team implemented in this cycle - CRI integration [1]. As known by people, Zun is an OpenStack Container service. It provides API for users to create and manage application containers in an OpenStack cloud. The main concepts in Zun are "Container" and "Capsule". A container is a single container, while a capsule is a group of co-located and co-scheduled containers (basically the same as k8s pod). Probably, the "Container" concept is more widely used. People can use the /containers API endpoint to create and manage a single container. Under the hook, a container is a Docker container in a compute node. What is special is that each Docker container is given a Neutron port so the container is connected to a tenant network in Neutron. Kuryr-libnetwork is the Docker network plugin we use to perform the Neutron port binding which basically connects the container to the virtual switch managed by Neutron. As mentioned before, the concept of "Capsule" in Zun is basically the same as pod in k8s. We introduced this concept mainly for k8s integration. Roughly speaking, the Zun-k8s integration is achieved by (i) registering a special node in k8s, (ii) watching the k8s API for pods being scheduled to this node and (iii) invoking Zun's /capsules API endpoint to create a capsule for each incoming pod. The (i) and (ii) is done by a CNCF sandbox project called Virtual Kubelet [2]. The (iii) is achieved by providing an OpenStack provider [3] for Virtual Kubelet. The special node registered by Virtual Kubelet is called a virtual node because the node doesn't physically exist. Pods being scheduled to the virtual node is basically offloaded from the current k8s cluster, eventually landed on an external platform such as an OpenStack cloud. In high level, what is offered to end-users is a "serverless kubernetes pod" [4]. This term basically means the ability to run pods on demand without planing the capacity (i.e. nodes) upfront. An example of that is AWS EKS on Fargate [5]. In comparison, the traditional approach is to create an entire k8s cluster upfront in order to run the workload. Let's give a simple example. Suppose you want to run a pod, the traditional approach is to provision a k8s cluster with a worker node. Then, run the pod on the worker node. In contract, the "serverless" approach is to create a k8s cluster without any worker node and the pod is offloaded to a cloud provider that provisions the pods at runtime. This approach works well for applications who have fluctuated workloads so it is hard to provision a cluster with the right size for them. Furthermore, from cloud provider's perspective, if all tenant users offloads their pods to the cloud, the cloud provider might be able to pack the workload better (i.e. with fewer physical nodes) thus saving cost. Under the hook, a capsule is a podsandbox with one or more containers in a CRI runtime (i.e. containerd). Compared to Docker, a CRI runtime has a better support for the pod concept so we chose it to implement capsule. A caveat is that CRI requires a CNI plugin for the networking, so we need to implement a CNI plugin for Zun (called zun-cni). The role of CNI plugin is similar as kuryr-libnetwork that we are using for Docker except it implements a different networking model (CNI). I summaries it as below: +--------------+------------------------+---------------+ | Concept | Container | Capsule (Pod) | +--------------+------------------------+---------------+ | API endpoint | /containers | /capsules | | Engine | Docker | CRI runtime | | Network | kuryr-libnetwork (CNM) | zun-cni (CNI) | +--------------+------------------------+---------------+ Typically, a CRI runtime works well with Kata Container which provides hypervisor-based isolation for neighboring containers in the same node. As a result, it is secure to consolidate pods from different tenants into a single node which increases the resource utilization. For deployment, a typical stack looks like below: +----------------------------------------------+ | k8s control plane | +----------------------------------------------+ | Virtual Kubelet (OpenStack provider) | +----------------------------------------------+ | OpenStack control plane (Zun, Neutron, etc.) | +----------------------------------------------+ | OpenStack data plane | | (Zun compute agent, Neutron OVS agent, etc.) | +----------------------------------------------+ | Containerd (with CRI plugin) | +----------------------------------------------+ | Kata Container | +----------------------------------------------+ In this stack, if a user creates a deployment or pod in k8s, the k8s scheduler will schedule the pod to the virtual node registered by Virtual Kubelet. Virtual Kubelet will pick up the pod and let the configured cloud provider to handle it. The cloud provider invokes Zun API to create a capsule. Upon receiving the API request to create a capsule, Zun scheduler will schedule the capsule to a compute node. The Zun compute agent in that node will provision the capsule using a CRI runtime (containerd in this example). The Zun-CRI runtime communication is done via a gRPC protocol through a unix socket. The CRI runtime will first create the pod in Kata Container (or runc as an alternative) that realizes the pod using a lightweight VM. Furthermore, the CRI runtime will use a CNI plugin, which is the zun-cni binary, to setup the network. The zun-cni binary is a thin executable that dispatches the CNI command to a daemon service called zun-cni-daemon. The community is via HTTP within localhost. The zun-cni-daemon will look up the Neutron port information from DB and perform the port binding. In conclusion, starting from Ussuri, Zun adds support for CRI-compatible runtime. Zun uses CRI runtime to realize the concept of pod. Using this feature together with Virtual Kubelet and Kata Container, we can offer "serverless kubernetes pod" service which is comparable with AWS EKS with Fargate. [1] https://blueprints.launchpad.net/zun/+spec/add-support-cri-runtime <https://github.com/virtual-kubelet/openstack-zun> [2] https://github.com/virtual-kubelet/virtual-kubelet [3] https://github.com/virtual-kubelet/openstack-zun [4] https://aws.amazon.com/about-aws/whats-new/2019/12/run-serverless-kubernete… [5] https://aws.amazon.com/blogs/aws/amazon-eks-on-aws-fargate-now-generally-av…

3 8

[all][TC][PTL][election] Nominations Close & Campaigning Begins
by Kendall Nelson 07 Apr '20

07 Apr '20

The PTL and TC Nomination periods are now over. The official candidate lists are available on the election website[0][1]. --PTL Election Details-- There are 16 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant Barbican Cloudkitty Congress I18n Infrastructure Loci Masakari Oslo Packaging_Rpm Placement Rally Swift Tacker Tricircle Zaqar There are no projects with more than one candidate so we won't need to hold any runoffs! Congratulations to our new and returning PTLs! [0] --TC Election Details-- The official candidate list is available on the election website[1]. There are will be a TC election following the campaigning period that has now begun and runs till Apr 07, 2020 23:45 UTC when the polling will begin. You are encouraged to ask questions to the candidates on the ML to help inform your decisions when polling begins. Thank you, -Kendall (diablo_rojo) & the Election Officials [0] https://governance.openstack.org/election/#victoria-ptl-candidates [1] https://governance.openstack.org/election/#victoria-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

8 10

[neutron][OVN] Multiple mechanism drivers
by Sam Morrison 07 Apr '20

07 Apr '20

We are looking at using OVN and are having some issues with it in our ML2 environment. We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network) Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc. It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks. Am I missing something here? (We’re using Stein version) Thanks, Sam

5 6

[openstack-discuss] [puppet] Nominating Takashi Kajinami for core of the Puppet OpenStack modules
by Shengping Zhong 07 Apr '20

07 Apr '20

Hey Puppet Cores, I would like to nominate Takashi Kajinami as a Core reviewer for the Puppet OpenStack modules. He is an excellent contributor to our modules over the last several cycles. His stats for the last 90 days can be viewed here[0]. Please response with your +1 or any objections. If there are no objections by April 6 I will add him to the core list. As there were no objections, I have added Takashi to the core list. Keep up the good work. Thanks, Shengping. [0] https://www.stackalytics.com/report/contribution/puppet%20openstack-group/90

5 4

[qa] Proposing Martin Kopec to Tempest core
by Ghanshyam Mann 07 Apr '20

07 Apr '20

Hello Everyone, Martin Kopec (IRC: kopecmartin) has been doing great contribution in Tempest since a long time. He has been doing bugs Triage also in Ussuri cycle and has good understanding of Tempest. I would like to propose him for Tempest Core. You can vote/feedback on this email. If no objection by the end of this week, I will add him to the list. -gmann

9 9

[kolla][uc] Kolla SIG
by Mark Goddard 02 Apr '20

02 Apr '20

Hi, I'd like to propose the creation of a Special Interest Group (SIG) [0] for Kolla. The main aim of the group would be to improve communication between operators and developers. The SIG would host regular virtual project onboarding, project update, and feedback sessions, ideally via video calls. This should remove the necessity of being physically present at Open Infra Summits for participation in the project. I like to think of this as the fifth open [1] (name TBD). I propose that in addition to the above sessions, the SIG should host more informal discussions, probably every 2-4 weeks with the aim of meeting other community members, discussing successes and failures, sharing knowledge, and generally getting to know each other a bit better. These could be via video call, IRC, or a mix. Finally - I propose that we build and maintain a list of Kolla users, including details of their environments and areas of interest and expertise. Of course this would be opt-in. This would help us to connect with subject matter experts and interested parties to help answer queries in IRC, or when making changes to a specific area. This is all up for discussion, and subject to sufficient interest. If you are interested, please add your name and email address to the Etherpad [2], along with any comments, thoughts or suggestions. [0] https://governance.openstack.org/sigs/ [1] https://www.openstack.org/four-opens/ [2] https://etherpad.openstack.org/p/kolla-sig Cheers, Mark

5 9

[all][dev][qa] cirros 0.5.1
by Radosław Piliszek 02 Apr '20

02 Apr '20

Hiya Folks, as you might have noticed, cinder 0.5.1 has been released. This build seems to be passing the current devstack gate. [1] Big thanks to hrw and smoser for letting cirros 0.5.1 happen (and cirros having bright future yet again). Also thanks to mordred for cleaning up SDK testing to pass. :-) I think it would be nice to merge this in Ussuri still, preferably before April. On the other hand, we all know that devstack gate is not super comprehensive and hence I would like to ask teams whose tests depend on interaction with guest OS to test their gates on this patch (or help me help you do that). I deliberately marked it W-1 to avoid merging too early. Let the discussion begin. :-) [1] https://review.opendev.org/711492 -yoctozepto

4 6

[tripleo] meeting notes from the last two weeks
by Wesley Hayutin 02 Apr '20

02 Apr '20

Greetings, I need to see why the openstack meeting bot is not in the #tripleo channel. A record was not automatically kept.. so here is the raw txt from the last two meetings.. I'll get the bot fixed asap. Meeting notes March 24 2020 [08:00:44] <weshay|ruck> #topic agenda [08:00:44] <weshay|ruck> * Review past action items [08:00:44] <weshay|ruck> * One off agenda items [08:00:44] <weshay|ruck> * Squad status [08:00:44] <weshay|ruck> * Bugs & Blueprints [08:00:44] <weshay|ruck> * Projects releases or stable backports [08:00:44] <weshay|ruck> * Specs [08:00:44] <weshay|ruck> * open discussion [08:00:44] <weshay|ruck> Anyone can use the #link, #action and #info commands, not just the moderatorǃ [08:00:44] <weshay|ruck> Hey folks! who's around? [08:00:57] <ekultails> o/ [08:00:59] <arxcruz|rover> o/ [08:01:03] <rlandy> o/ [08:01:11] <tkajinam> o/ [08:01:18] <rfolco> o/ [08:01:24] <pkopec> o/ [08:01:41] <owalsh> o/ [08:01:45] <jbadiapa> o/ [08:02:24] <ysandeep> ysandeep, o/ [08:02:27] <weshay|ruck> #topic review past action items [08:02:27] <weshay|ruck> http://eavesdrop.openstack.org/meetings/tripleo/2020/ [08:02:42] <weshay|ruck> anyone need to raise anything from a previous meeting? [08:03:07] <weshay|ruck> None. [08:03:07] <weshay|ruck> #topic one off agenda items [08:03:07] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:03:17] <Tengu> «o/ [08:03:18] <weshay|ruck> I added two items to the agenda.. [08:03:27] <weshay|ruck> please add something if you have it.. [08:03:53] * weshay|ruck notes that rdo-cloud the 3rd party ci platform is in a scheduled maint window today [08:04:03] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: Refactorize test_tht_ansible_syntax to welcome new roles/modules https://review.opendev.org/713669 [08:04:05] <weshay|ruck> the ctrl plane is moving to vexxhost [08:04:10] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: standalone/overcloud: enable the HA deployment by default https://review.opendev.org/359060 [08:04:16] <weshay|ruck> should be back by tomorrow [08:04:18] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: Deprecate Keepalived service https://review.opendev.org/657067 [08:04:28] <fultonj> o/ [08:04:33] <marios> hi [08:04:36] <weshay|ruck> any questions? [08:04:43] <weshay|ruck> EmilienM, stop working :) [08:04:45] <cloudnull> o/ [08:04:49] <leanderthal> o/ [08:04:50] <sshnaidm> o/ [08:04:53] <EmilienM> o/ [08:05:01] <weshay|ruck> leanderthal, you may want to get the testday on the agenda :) [08:05:12] <leanderthal> ooOOOooh good call [08:05:19] <weshay|ruck> ok.. the next topic is around bugs [08:05:34] <beagles> o/ [08:05:49] <weshay|ruck> we were up to 60 untriaged bugs last week.. a lot of folks do NOT have access to self triage and that's fine [08:06:09] <weshay|ruck> but if are a member of the tripleo org in launchpad.. we'd hope that you do follow the triage process [08:06:15] <sshnaidm> don't we run a meeting bot? [08:06:21] <weshay|ruck> So Question for the group... [08:06:23] <weshay|ruck> sshnaidm, yes [08:06:38] <weshay|ruck> but maybe it's down.. ? [08:06:40] <weshay|ruck> don't know [08:07:06] <weshay|ruck> Question... Any objects to closing any bugs in marked "New" ( untriaged ) older than 365 days? [08:07:11] <weshay|ruck> objection rather [08:07:17] <marios> weshay|ruck: sounds good to me [08:07:25] <beagles> k [08:07:31] <marios> weshay|ruck: but 'latest updated ' date right? [08:07:45] <weshay|ruck> ya.. I'll account for that... good point [08:07:47] <marios> weshay|ruck: not filed? maybe doesn't matter 365 is long enough that it either /or [08:07:50] <chandankumar> fultonj, fmount https://bugs.launchpad.net/tripleo/+bug/1868731 thanks for looking into that [08:07:51] <openstack> Launchpad bug 1868731 in tripleo "ceph_ansible_skip_tags is getting ignored during multinode overcloud deploy" [Critical,Triaged] [08:07:56] <beagles> (wrong window) but yeah, that sounds reasonable [08:08:02] * florianf (~flfuchs@2a02:8109:9280:1aa8:8bb0:31ca:8557:482c) has joined [08:08:09] <fultonj> chandankumar: thanks [08:08:15] <weshay|ruck> I'll send an email to the list to have folks reopen if they need it [08:08:30] <weshay|ruck> ok.. seeing no objections... we'll go ahead and clean it up :) [08:08:47] <weshay|ruck> #topic one off agenda items [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:08:47] <weshay|ruck> #topic Active Squad status [08:08:47] <weshay|ruck> ci [08:08:47] <weshay|ruck> #link https://hackmd.io/IhMCTNMBSF6xtqiEd9Z0Kw?both [08:08:47] <weshay|ruck> validations [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-validations-squad-status [08:08:47] <weshay|ruck> ceph-integration [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-integration-squad-status [08:08:47] <weshay|ruck> transformation [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-ansible-agenda [08:08:47] <weshay|ruck> mistral-to-ansible [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-mistral-to-ansible [08:09:00] <weshay|ruck> any reviews needed by the squads? [08:09:05] * TrevorV (~TrevorV(a)130-45-79-246.dyn.grandenetworks.net) has joined [08:09:17] <Tengu> validations: we have our package under TripleO governance! [08:09:25] <Tengu> it's been merged today. [08:09:50] <weshay|ruck> rdo governance :) [08:09:51] <cloudnull> weshay|ruck the following reviews would be great to get some eyes on - https://review.opendev.org/#/q/starredby:cloudnull+status:open,n,z [08:10:12] <weshay|ruck> thanks cloudnull [08:10:41] <weshay|ruck> fultonj, I mentioned this earlier.. but ansible 2.9 is being tested along side the latest ceph-ansible.. I don't have a ton of detail on that [08:11:02] * derekh (~derekh(a)93.107.228.126) has joined [08:11:15] <weshay|ruck> ok.. let's move on [08:11:19] <fultonj> weshay|ruck: ack [08:11:26] <weshay|ruck> #topic Moderately Active Squads [08:11:26] <weshay|ruck> Ironic-integration [08:11:26] <weshay|ruck> https://etherpad.openstack.org/p/tripleo-ironic-integration-squad-status [08:11:26] <weshay|ruck> upgrade [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-upgrade-squad-status [08:11:26] <weshay|ruck> edge [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-edge-squad-status [08:11:26] <weshay|ruck> networking [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-networking-squad-status [08:11:47] <weshay|ruck> probably nothing new here [08:11:59] <weshay|ruck> #link https://launchpad.net/tripleo/+milestone/ussuri-3 [08:12:31] <weshay|ruck> 5 New, 28 Incomplete, 4 Invalid, 4 Won't Fix, 4 Confirmed, 385 Triaged, 120 In Progress, 2 Fix Committed, 151 Fix Released [08:12:50] <weshay|ruck> not bad on the bug counts.. I guess [08:13:00] <weshay|ruck> Storyboard bugs. [08:13:00] <weshay|ruck> #link https://storyboard.openstack.org/#!/project_group/76 [08:13:48] <cloudnull> weshay|ruck we've recently updated the mistral_to_ansible board - https://storyboard.openstack.org/#!/board/208 [08:14:17] <weshay|ruck> very nice.. [08:14:31] <weshay|ruck> k.. will include that in the future [08:14:53] <weshay|ruck> There are two blueprints not started for ussuri [08:14:54] <weshay|ruck> Medium tripleo-firewall-rule-reporting New Not started ussuri [08:14:54] <weshay|ruck> Medium remove-puppet Drafting Not started Emilien Macchi ussuri [08:15:02] * amoralej|lunch is now known as amoralej [08:15:20] <weshay|ruck> EmilienM, maybe we move that to the next release or future at this point... [08:15:30] <weshay|ruck> April 20th is m3 I think [08:15:52] <weshay|ruck> and dsneddon owns https://blueprints.launchpad.net/tripleo/+spec/tripleo-firewall-rule-report… [08:16:10] <weshay|ruck> #topic specs [08:16:10] <weshay|ruck> #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open [08:16:39] <weshay|ruck> reviews for luke please https://review.opendev.org/#/c/698828/ on [08:16:39] <weshay|ruck> Add spec for AWX integration. [08:16:55] <weshay|ruck> #topic open discussion [08:16:55] <weshay|ruck> Anything else that folks want to bring up to the meeting? [08:17:07] <EmilienM> weshay|ruck: i'll probably abandon it for now [08:17:12] <weshay|ruck> k.. thanks [08:17:27] <weshay|ruck> anyone else ? [08:17:30] <weshay|ruck> going once [08:17:36] <weshay|ruck> going twice [08:17:43] <marios> weshay|ruck: [08:17:46] <weshay|ruck> #endmeeting tripleo [08:17:49] <marios> do we wantto consider virtual ptg [08:17:53] <marios> weshay|ruck: ? [08:17:54] <weshay|ruck> I'll save the meeting notes [08:17:57] <marios> weshay|ruck: next time then [08:17:58] <marios> ... [08:17:58] <weshay|ruck> marios, that's still not clear [08:18:04] <weshay|ruck> but most likely [08:18:06] <cloudnull> +1 for virt ptg Meeting notes from March 30 2020 <weshay> #topic agenda [08:01:02] <weshay> * Review past action items [08:01:02] <weshay> * One off agenda items [08:01:02] <weshay> * Squad status [08:01:02] <weshay> * Bugs & Blueprints [08:01:02] <weshay> * Projects releases or stable backports [08:01:02] <weshay> * Specs [08:01:02] <weshay> * open discussion [08:01:02] <weshay> Anyone can use the #link, #action and #info commands, not just the moderatorǃ [08:01:02] <weshay> Hey folks! who's around? [08:01:08] <EmilienM> o/ [08:01:18] <ekultails> o/ [08:01:20] <Tengu> ybe [08:01:22] <fultonj> o/ [08:01:24] <rlandy> o/ [08:01:27] <weshay> EmilienM, aye.. I'll get into that [08:01:28] <Tengu> *maybe [08:02:28] <tkajinam> o/ [08:02:30] <ysandeep|rover> o/ [08:02:36] <mwhahaha> o/ [08:02:42] <chandankumar> \o/ [08:04:24] <marios> o/ [08:05:05] <beagles> o/ [08:05:05] <weshay> #topic review past action items [08:05:05] <weshay> http://eavesdrop.openstack.org/meetings/tripleo/2020/ [08:05:05] <weshay> None. [08:05:14] <weshay> #topic one off agenda items [08:05:14] <weshay> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:05:27] <weshay> ok.. virt ptg.. /me pastes from the agenda some info [08:05:38] <weshay> * Virtual PTG for TripleO [08:05:38] <weshay> * https://etherpad.openstack.org/p/tripleo-victoria-topics [08:05:38] <weshay> * http://lists.openstack.org/pipermail/foundation/2020-March/002854.html [08:05:38] <weshay> * https://www.openstack.org/events/opendev-ptg-2020/ [08:05:38] <weshay> * https://etherpad.openstack.org/p/Virtual_PTG_Planning?_ga=2.148734014.82059… [08:05:38] <weshay> [08:05:38] <weshay> * planning email sent out by foundation - dates for ptg virt event not yet know. [08:05:38] <weshay> * dates for planning [08:05:38] <weshay> - April 2nd at 12:00 UTC [08:05:38] <weshay> - April 6th at 17:00 UTC [08:05:38] <weshay> - April 7th at 2:00 UTC [08:05:38] <weshay> [08:05:53] <arxcruz> o/ [08:06:08] <weshay> I'm going to join the last two mtgs there on the 6th and 7th... [08:06:38] <weshay> once we get dates.. we'll be sending out a email to confirm who would like to attend.. just like previous in person ptg's [08:07:05] <weshay> any questions about the ptg in general before we get into tripleo specific ptg topics [08:07:17] <weshay> hello [08:07:23] <weshay> is it me your looking for? [08:07:23] <marios> weshay: hav we considered the details ... sessions will be in bluejeans? or irc? [08:07:26] <marios> weshay: timezones? [08:07:30] marios maciejjozefczyk Madkiss mandre marbindrakon matbu [08:07:38] <marios> weshay: ah i see you have time already there [08:07:43] <weshay> marios, I assume that will be addressed in these planning sessions [08:08:02] <weshay> note.. those dates are NOT the ptg.. they are PLANNING events FOR the ptg [08:08:05] <weshay> :) [08:08:06] <gfidente> o/ [08:08:07] <marios> weshay: k (the times you have there are for the planning) [08:08:07] <marios> ack [08:08:12] <weshay> aye [08:08:25] <weshay> there is a sign up sheet for the planning.. if you are interested [08:08:34] <weshay> OK.. thanks for responding [08:08:36] <weshay> marios++ [08:08:37] <marios> weshay: perhaps this can just be worked out amongst the folks interested in each session... and we don't need to mandate a way/time [08:08:57] <weshay> there is no mandate for ptg.. volunteers only :) [08:09:08] <weshay> so.. TLDR.. details pending on ptg [08:09:15] <weshay> now for tripleo [08:09:15] <weshay> https://etherpad.openstack.org/p/tripleo-victoria-topics [08:09:37] <weshay> as usual.. please add topics to this list, w/o topics we have no agenda [08:09:57] <weshay> I'll be adding a few myself :) [08:09:59] <marios> weshay: we could overview/presentation about the component pipeline & how it affect how we promote now [08:10:05] * markllama (~mark5163(a)72.32.180.178) has joined [08:10:07] marios maciejjozefczyk Madkiss mandre marbindrakon markllama matbu [08:10:13] <EmilienM> marios++ [08:10:44] <weshay> marios, yes.. usually there is an hour for CI at the ptg.. the new dlrn structure and component based ci is a good topic imho [08:11:02] <Tengu> +42 [08:11:42] <weshay> I would assume that new features.. validation, ansible collections, tripleo-operators should be added to the topic list [08:11:48] <weshay> tripleo-ansible etc [08:12:09] <weshay> any questions about tripleo + ptg? [08:12:27] <Tengu> I'll check with my folks about the validation part. [08:12:32] <weshay> +1 [08:12:39] <Tengu> maybe the container would be nice. [08:13:11] <weshay> EmilienM, you have anything to add? [08:13:36] <EmilienM> not now, indeed we need to come with more topics [08:13:44] <EmilienM> I'll try to gather some from the team [08:14:05] <weshay> ya.. I am looking for parity from previous ptg's.. minus the last one [08:14:32] <weshay> we did not have a lot of folks in china for the last ptg.. and I would expect a backlog of topics [08:14:45] <weshay> so we'll be covering that here for a few weeks I'm sure [08:14:47] <weshay> anyhoo [08:14:50] <weshay> #topic Active Squad status [08:14:50] <weshay> ci [08:14:50] <weshay> #link https://hackmd.io/IhMCTNMBSF6xtqiEd9Z0Kw?both [08:14:50] <weshay> validations [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-validations-squad-status [08:14:50] <weshay> ceph-integration [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-integration-squad-status [08:14:50] <weshay> transformation [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-ansible-agenda [08:14:50] <weshay> mistral-to-ansible [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-mistral-to-ansible [08:14:56] <weshay> where is the bot? [08:14:57] * haleyb (haleyb@nat/redhat/x-koblohkdhoozsgkh) has joined [08:15:09] <weshay> dang [08:15:26] <weshay> second week in a row.. I'll look into why the meeting bot is not active.. [08:15:32] * bogdando has quit (Ping timeout: 256 seconds) [08:15:48] <weshay> ok.. the point now of calling squads... again... is to facilitate reviews [08:16:02] <weshay> in a more public fashion [08:16:20] <cloudnull> o/ [08:16:27] <weshay> so just a reminder... guidance is to spend 30-60 minutes per day reviewing other peoples code [08:16:32] * bnemec (~bnemec(a)96-41-255-59.dhcp.eucl.wi.charter.com) has joined [08:16:55] <weshay> if you are not doing that.. you're doing opensource wrong :) [08:17:00] <cloudnull> ++ [08:17:32] <weshay> so.. w/o calling out folks specifically... anything that needs attention? [08:18:12] <cloudnull> work on removing mistral is going great: https://review.opendev.org/#/q/starredby:cloudnull+status:open,n,z - these are some reviews that are inflight and we'd greatly appreciate if folks could take a look at them. [08:18:21] <weshay> ++ [08:18:35] <marios> weshay: '3 a day' ;) [08:18:42] <weshay> ++ [08:18:49] <marios> used to be a minimum requirement to be core [08:19:08] <weshay> ya.. hasn't changed.. [08:19:21] * markllama has quit (Ping timeout: 256 seconds) [08:19:24] <marios> weshay: yeah but it used to be enforced more enthusiastically ;) [08:19:26] <weshay> well.. I can show everyone what we look for in cores.. I'll add that to next weeks agenda [08:19:36] <marios> s/enthusiastically/stricly [08:19:41] <marios> strictly even you know what i mean [08:19:49] <weshay> ya.. VERY open in ideas to help facilitate reviews.. [08:20:04] <weshay> all projects struggle w/ that.. but new ideas are welcome [08:20:18] <openstackgerrit> Rabi Mishra proposed openstack/python-tripleoclient master: Fix _get_image() of GlanceClientAdapter to call find_image() https://review.opendev.org/716277 [08:20:20] <weshay> ok.. /me ends the lecture [08:20:31] <weshay> #topic Moderately Active Squads [08:20:31] <weshay> Ironic-integration [08:20:31] <weshay> https://etherpad.openstack.org/p/tripleo-ironic-integration-squad-status [08:20:31] <weshay> upgrade [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-upgrade-squad-status [08:20:31] <weshay> edge [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-edge-squad-status [08:20:31] <weshay> networking [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-networking-squad-status [08:20:31] <weshay> Any squad wanting to bring up their status, or a topic for the general public? [08:20:47] <weshay> #link https://launchpad.net/tripleo/+milestone/ussuri-3 [08:20:58] <Tengu> validations: we're aiming to get our code in train [08:21:08] <Tengu> at least for the new packages - validations-common and validations-libs. [08:21:16] <weshay> 5 New, 28 Incomplete, 5 Invalid, 5 Won't Fix, 4 Confirmed, 378 Triaged, 120 In Progress, 2 Fix Committed, 189 Fix Released [08:21:26] <weshay> Tengu++ [08:21:46] <Tengu> doing so will allow to get a clean code and, well, make our life easier on Red Hat side. [08:21:49] <weshay> Tengu, I see ptg topics in your future :) [08:22:00] * bnemec has quit (Read error: No route to host) [08:22:03] <Tengu> weshay: yep, maybe ;). [08:22:19] <Tengu> (hint: just dropped a mail to my team ;)) [08:22:21] <weshay> so.. bug triage will continue as I have time... just a reminder anything older than 365 days and in new.. will be closed [08:22:40] <weshay> Storyboard bugs. [08:22:40] <weshay> #link https://storyboard.openstack.org/#!/project_group/76 [08:23:02] <weshay> reminder.. be nice to the infra folks and folks driving storyboard... volunteer effort there.. [08:23:16] <openstackgerrit> Martin Kopec proposed openstack/ansible-role-collect-logs master: Extend infrared molecule tests https://review.opendev.org/705552 [08:24:27] * weshay notes... [08:24:40] <weshay> now is the time to start thinking about blueprints and specs for the next cycle [08:24:49] <weshay> here's a dump on ussuri [08:24:50] <weshay> Medium ansible-certmonger Approved Unknown Cédric Jeanneret ussuri [08:24:50] <weshay> Medium ironic-overcloud-ci Approved Slow progress Derek Higgins ussuri [08:24:50] <weshay> Medium multiarch-support Approved Good progress Tony Breeds ussuri [08:24:50] <weshay> Medium nova-less-deploy Approved Good progress Steve Baker ussuri [08:24:50] <weshay> Medium replace-keepalived-undercloud Approved Good progress Emilien Macchi ussuri [08:24:50] <weshay> Medium split-controlplane-workflow Approved Unknown ussuri [08:24:50] <weshay> Medium remove-puppet Drafting Not started Emilien Macchi ussuri [08:24:50] <weshay> Medium tripleo-firewall-rule-reporting New Not started ussuri [08:24:50] <weshay> Undefined tripleo-mistral-to-ansible Approved Good progress Dougal Matthews ussuri [08:25:07] * Tengu hides [08:25:34] <openstackgerrit> Martin Kopec proposed openstack/ansible-role-collect-logs master: Extend infrared molecule tests https://review.opendev.org/705552 [08:25:48] <weshay> ekultails, looks like progress on https://review.opendev.org/698828 [08:25:56] <weshay> Add spec for AWX integration. [08:25:58] <weshay> FYI ^ [08:26:17] <EmilienM> replace-keepalived-undercloud is WIP and waiting on HA byd efault, blocked by not having upgrade jobs on centos8 [08:26:29] <EmilienM> remove-puppet is not in progress, I'm not working on it [08:26:30] <Tengu> for the ansible-certmonger, it's in the Security capable hands, not mine... I just pushed the idea ^^' [08:26:48] <Tengu> ade_lee: -^^ [08:26:55] <weshay> aye.. EmilienM working in the background on that for you... getting advice on the priority for train + centos8 [08:27:43] <weshay> need help reviewing https://review.opendev.org/#/c/715734/ Add new project and repository for tripleo-compute-extras [08:27:45] <weshay> as well folks [08:28:08] <weshay> k.. /moving on [08:28:12] <weshay> #topic open discussion [08:28:12] <weshay> Anything else that folks want to bring up to the meeting? [08:28:26] <weshay> FYI.. I've nominated myself for ptl in victoria.. [08:28:32] <EmilienM> yay! [08:28:34] <Tengu> weshay: you'll get my vote for ptl :) [08:28:45] <fultonj> +1 [08:28:59] * zzzeek has quit (Quit: bye) [08:29:00] <weshay> I would like to help others this cycle better understand what is involved.. and the how-to's to the best of my ability :) [08:29:21] <weshay> so if you are interested in perhaps being ptl.. after victoria.. let me know and I'm happy to walk through it [08:29:50] <weshay> that's it from me.. anyone else have anything new? [08:30:14] <weshay> once [08:30:15] <weshay> twice [08:30:18] <weshay> #endmeeting tripleo [08:30:23] <weshay> thanks all :)

2 2

[election][octavia][ptl] Announcing my PTL candidacy for Octavia
by Michael Johnson 02 Apr '20

02 Apr '20

My fellow OpenStack community, I would like to nominate myself for Octavia PTL during the Victoria cycle. I have previously led the team during the Stein release, and I would like to continue helping our team provide network load balancing services for OpenStack. Looking forward to Victoria I expect the team to finish some major new features, such as the Jobboard transition and introducing HTTP/2 support. Thank you for your support and your consideration for Victoria, Michael Johnson (johnsom)

2 1

[tempest] what is a proper way to install a package into a vm instance spawned by tempest?
by Roman Safronov 01 Apr '20

01 Apr '20

Hi, I wrote a tempest test <https://review.opendev.org/#/c/710975/https://review.opendev.org/#/c/710975/)> which requires keepalived to be running inside vm instance. The test tries to install keepalived package inside vm by running "apt install/yum install". However as I see in upstream gates logs this does not work while the same code works perfectly in our downstream CI using the same image. Do vm instances spawned on upstream gates during tests have a route to the internet? Is there an alternative way that I can use in order to install a package? Thanks in advance -- ROMAN SAFRONOV SENIOR QE, OPENSTACK NETWORKING Red Hat <https://www.redhat.com/> Israel M: +972545433957 <https://red.ht/sig>

4 6

[tosca-parser][heat-translator][tacker] - Need new version of heat-translator and tosca-parser libraries for Tacker
by Patil, Tushar 01 Apr '20

01 Apr '20

Hi PTL and Core Reviewers, We are working on implementing ETSI spec in tacker for Ussuri release for which we have pushed couple of patches in heat-translator [1][2] and tosca-parser[3]. Patch [1] is not yet merged so request core reviewers to please take a look at it. We have uploaded many patches in tacker [4] but most of the patches are failing on CI as it's requires changes from heat-translator and tosca-parser. So we need a new release of heat-translator (after patch [1] is merged) and tosca-parser badly. Please let us know when are you planning to release a new version of these libraries. [1] : https://review.opendev.org/#/q/status:merged+project:openstack/heat-transla… [2] : https://review.opendev.org/#/q/status:open+project:openstack/heat-translato… [3] : https://review.opendev.org/#/c/688633 [4] : https://review.opendev.org/#/q/topic:bp/support-etsi-nfv-specs+(status:open… Thank you. Regards, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 2

[election][ptl][swift] Tim Burke candidacy for Swift PTL
by Tim Burke 01 Apr '20

01 Apr '20

It would be my honor and pleasure to continue serving you as Swift PTL. The world continues to generate and retain ever-increasing amounts of data, and Swift continues to rise to the challenge of storing that data durably and making it highly available. I'm excited to help us engineer now to be ready for next year's data-center demands. To that end, there are several projects we'll be advancing; in general, these are not short-term, though some pieces will surely come in the next cycle. As hard-drive sizes increase, the lots-of-small-files problem has become a lots-of-files problem. Between 16TB hard drives hitting the market and cost concerns pushing us toward ever more drives per box, even historically "reasonable" object sizes will produce noticeable memory pressure that we'd like to reduce. OVH's explorations in this space give us all a leg up that we should take advantage of. As clusters grow, we must ensure Swift can scale with them. Some aspects of that will be relatively straight-forward, like allowing rings to support more than 64k devices. Other challenges are less well-defined; there are likely improvements that could be made in replication and backend protocols, for example, but there is no single way forward. There will likely be some experiments that never land on master -- but as long as they are in the open and we can all learn from them, they will not be failures. All of that must be driven by what we learn by operating real clusters at scale. To do that, we must improve our metrics and monitoring, and find ways to observe the system dynamically. Post-facto log analysis is not tenable when dealing with tens of thousands of requests per second across hundreds of nodes. At the same time, we cannot neglect our client ecosystem. This extends not just to python-swiftclient, but to S3 clients as well. For better or worse, S3 has become the de facto standard interface for object storage, and we must ensure our compatibility is as seamless as possible. This cycle we added S3-compatible versioning, but there is so much more we could be doing, from object life-cycle management to bucket inventories. As always, we will listen to our users and prioritize addressing their pain points. Tim Burke ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

1 0

[elections][tc] Nomination
by Radosław Piliszek 01 Apr '20

01 Apr '20

Dear Fellow OpenStackers, I am Radosław Piliszek (yoctozepto) and I am proposing myself as a TC candidate starting Victoria cycle. For the record, I have never been in TC nor a PTL... yet. I am affiliated with a relatively small Polish university: University of Białystok, with the local Computing Centre offering services to local academics. My experience is broad in that this work involves being a whole IT department at once. :-) OpenStack piqued my interest in 2018 when I joined the Foundation as an individual member. Since then I made myself COA (Certified OpenStack Administrator), learnt the jump from "administrator" to "operator" while deploying locally various PoC instances of basic OpenStack services and finally started contributing upstream via bug reports, patches and reviews. I was (and am!) really proud to have been recognized Kolla core due to my work with fellow project members. Later on, DevStack core nomination followed for which I am grateful as well. In the Kolla project I work mostly on ensuring sanity, enhancing testing and fixing current issues while helping fellow contributors to deliver their features and fixes. I also managed to deliver a bigger change in the Train cycle: all-around IPv6-only networking support. I enjoyed the cross-project aspect of this and decided to contribute a bit to the development experience as well and this is how I ended up DevStack core (true story). Nowadays I am wearing multiple hats in the wide community and many of you probably recognize me from IRC where I try to be helpful but also ask questions around (often technical ones like: to be or not to be?). One could say I'm inquisitive (hopefully in the good sense of this word) and in fact I value highly a deeper insight into the problem at hand (probably due to bad experience with hasty actions!). I react to issues quite quickly (bothering infra from time to time - I am really sorry, you folks are doing great job!) and work on solutions with fellow OpenStackers (aka you) which brings real joy and makes experience real. I have a few, rather broad, goals (or thoughts?) of mine: 1) To test, test and test. My motto is: "not tested = not working". Unfortunately, this is actually often the case in reality. :-( Hence, I encourage thorough testing, especially at the functional and integration level. I believe we need to be reliable to be trustworthy. 2) To make OpenStack easily consumable by small companies, especially in public academia but not only. Everyone deserves a good private cloud experience with decent learning curve. This involves prompt and current documentation but also reliable base for installs. (1) and (2) culminate in (3) [1+2=3 - could not have been simpler!] 3) Who are we? BUILDERS! What do we want? TO BUILD! (I hope you know the meme!) Ultimately OpenStack is software built for specific purpose and is meant to be consumed by cloud operators. We have plenty of ways to get OpenStack "installed" but officially we still rely on the archaic assumption that everything is thrown in the same environment. This is rarely the case nowadays due to various layers of separation being applied: virtual envs, OCI images. It would be beneficial to be able to rely on prebuilt official images of OpenStack services and their prerequisites, also for CI. We don't need to rebuild/reinstall keystone, glance, nova and swift just to test neutron that one more time, only to discover pip hangs installing dep of dep of not-even- neutron due to random networking issue.* Similarly this is wasted effort in case of multinode testing. Multiply this by the amount of scenarios and... well, you probably get the picture. I know we can do better: deliver more reliability via more reliability. * Order random for example purposes. This is as many relevant bits as I thought necessary to introduce my candidacy and share my mind with you. Thank you for reaching this far. Radosław Piliszek (yoctozepto) https://review.opendev.org/716363

1 0

[tc][elections] Nomination for TC
by Tobias Rydberg 01 Apr '20

01 Apr '20

Hi fellow Stackers, My name is Tobias Rydberg and I will by this email announce my candidacy for the OpenStack Technical Committee. For those who (yet) don't know me, I'm employed by the cloud provider City Network and through that I've been around and worked with OpenStack since 2014 when we as City Network started our OpenStack journey. I'm a simple person that speak my mind, love to have fun and get to know new people and technologies - and I have to say that being part of this community ticks a lot of those boxes. During the last couple of years I've been chair for the Public Cloud SIG (previously WG), and in that role you might have seen me hosting Forum sessions at all Summits since the Forum was introduced, spreading the word of why OpenStack is super important for public clouds (the Public Cloud Passport Program is a child of PC SIG) and what is still missing... ;-) Even though I'm a developer from the get go, I haven't done a lot of code contributions over the years, but I have tried to contribute in various other ways where being SIG chair is one, driving discussions in the Forums and being part of organising OpenStack days events (Nordic). So, what can I bring to the table? I believe that my background (and precent) with multiple years of running multiple public and private clouds will bring a lot of operator experience. We've over the years also been very focused to deliver OpenStack to customers with very high regulatory compliance demands, such as banks, health care, insurance industry, and as I see it, that is a pretty hot potato right now and I believe that will not cool down for some time. I my current role I have the blessing of talking a lot with customers building their services on top of OpenStack, listening to their experience and feedback - everything from how hard it can be to find the correct piece of documentation to limitations that hinders them from choosing OpenStack as a platform for their service - valuable feedback that not always reach the community. I think that the continued success of OpenStack (for at least 10 more strong years) lies in the hands of the "operators" - the people and the companies that live and breathe OpenStack - the people and the companies that have the experience how OpenStack operates in all the different use cases you can't predict in a public cloud. This is my first time running for a chair at the TC table, my experience of sitting in such chair is by that pretty limited, but I care a lot about this awesome community and I'm eager to learn and to do my fair share to make this community a success to the years to come... Thanks for taking the time to read and to consider my candidacy! Cheers, Tobias

1 0

Upcoming pip changes - stop installing test-requirements in devstack
by Monty Taylor 01 Apr '20

01 Apr '20

Heya, Recently we had to revert a change to devstack that ran pip check. This is a recommendation from the pip team to verify that upcoming addition of a depsolver to pip isn’t going to break us. Well - it is going to break us. The reason it’s going to break us is that we don’t apply constraints to linters (so that projects can deal with those at their own rate) BUT - we install every project’s test-requirements.txt (containing the linters) when we run devstack. That means we uninstall and reinstall flake8 at different versions over and over again - and the final state is not one that is completely consistent. I’ve pushed up this: https://review.opendev.org/#/c/715469/ Which is a patch to stop installing test-requirements in devstack. Realistically we should not need to install this in devstack. Devstack is installing the software which does not need test-requirements - and then we test it with tempest which has its own set of requirements. As a side benefit, devstack is quicker and none of the non-voting jobs on devstack fail now. It’s possible this change could impact people using devstack as a base for single-project functional tests - so it’s worth being careful with. But I think we should get it done and then re-add the pip check as a verification that we’re not going to get broken this summer. Monty

4 4

[charms][ptl][election] PTL Non-candidacy
by Frode Nordahl 31 Mar '20

31 Mar '20

Hello all, The Ussuri cycle is coming to an end and the contributors to the Charms project has done great progress in the key areas we set afoot at the beginning of the cycle. We have also had good participation from the broader community and I hope to see that flourish further in the coming cycles. I believe rotating leadership for open source projects is a good thing and I am happy to pass on the relay baton for the Victoria cycle. -- Frode Nordahl

1 0

[all][elections][ptl][tc] Conbined PTL/TC Nominations Last Days
by Kendall Nelson 31 Mar '20

31 Mar '20

Hello Everyone! A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Mar 31, 2020 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2020-03-24 23:45:00 UTC Nominations end @ 2020-03-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 8:25:21 Nominations progress : 94.99% --------------------------------------------------- Projects[1] : 60 Projects with candidates : 0 ( 0.00%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 60 (Adjutant Barbican Blazar Cinder Cloudkitty Congress Cyborg Designate Ec2_Api Freezer Glance Heat Horizon I18n Infrastructure Ironic Karbor Keystone Kolla Kuryr Loci Magnum Manila Masakari Mistral Monasca Murano Neutron Nova Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms OpenStack_Helm Openstack_Chef Oslo Packaging_Rpm Placement Puppet_OpenStack Qinling Quality_Assurance Rally Release_Management Requirements Sahara Searchlight Senlin Solum Storlets Swift Tacker Telemetry Tricircle Tripleo Trove Vitrage Watcher Winstackers Zaqar Zun) =================================================== Stats gathered @ 2020-03-31 15:19:39 UTC This means that with approximately 2 days left, 60 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, Kendall Nelson(diablo_rojo) & the Election Officials [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[blazar][election][ptl] PTL candidacy for Victoria
by Pierre Riteau 31 Mar '20

31 Mar '20

Hi, I would like to self-nominate to serve as PTL of Blazar for the Victoria release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. As with many other projects, we are struggling with a lack of contributions. My focus will be to keep our small community active, help new contributors to be more involved in the project, and deliver functionality that will encourage further adoption. Thank you for your support, Pierre Riteau (priteau)

2 1

[nova] Proposing Ghanshyam Mann as nova core
by Balázs Gibizer 31 Mar '20

31 Mar '20

Hi, I'm proposing Ghanshyam Mann to the core team. He is a long time OpenStack and nova contributor. He is one of our API and QA expert. I think he would be a great addition to the team. Cores, please vote (-1, 0, +1) before next Monday (03.30.) Cheers, gibi

8 8

[nova] Proposing Lee Yarwood as nova core
by Balázs Gibizer 31 Mar '20

31 Mar '20

Hi, I'm proposing Lee to the core team. He is around for a long time and he became really active recently not only on the stable branches. I think he would be a great addition to the team. Cores, please vote (-1, 0, +1) before next Monday (03.30.) Cheers, gibi

8 8

[tc][election] Add Rico Lin candidacy for Victoria TC role
by Rico Lin 31 Mar '20

31 Mar '20

Dear all, It has been a great year for me to work on TC and work as TC vice-chair, and I do like to join TC election again and keep serving this community as TC member if I have the honor. In the past year, I have been working on the following tasks: * TC vice-chair: I thank for the vice-chair roles allows me to dive in deeper on TC activity. As we work on TC's daily support for TC chair. IMO, JP shows some nice example to running TC chair by standardizing routine processes. And I do feel it's great to work with him. And from what I learned, to consistent checking on actions for TCs is something we should keep on. Also ML update and host meetings. What I think we should try in advance are keep pushing TC plus UC merging task, and work on providing better decision system so we can make sure at the end of discussion, we have something put into actions and that's been decided by TCs as a group. * Meta SIG chair: It's a great opportunity to working on SIG govern, which works with coordination between devs, ops, and users. We achieved on items like pushing more new SIGs, create SIG guidelines, track SIG status, and of course general SIG govern stuff. But SIGs still needs more attention. Which is one of the goals I have to push SIG forward (And I'm happy to have others as Meta SIG chair). IMO SIG only successful when it can provide a better bridge across all roles. That's something we need to keep pushing our effort to expose SIGs. * Comparison of Official Group Structures: I also work on providing [1] so whoever join this community, can have better understanding on how we works. Over time, our structure require changes, so we can evolve and provide understandable structures for the whole time (and for old and new members). What we can keep working on is to consistently review the structure flow, to make sure everything makes sense for a community to allow consistency and evolution. Also as mentioned, to combine TC and UC, will require more review on structure to make sure teams all get benefits from the achievement we plan. * Cross culture bridge: This is something I'm reeeally proud of. To help community members reach better communication despite language, culture, and timezone barriers. I get the honor to serve a great number of community members on this task, and I'm proud of it. This also alerts me that we need more members in community to become the bridge. We have some great people to keep working on this, but we simply need more from different languages, cultures, and timezone. So community members can have a better way to reach to TCs. * community goal schedule: gmann doing really good job on keep community-wide goal forward. As we implemented our goal schedule to cover from pre-select, select, and implementation schedule. I'm planning to keep govern that process to make sure we jump in the correct routine. [1] https://governance.openstack.org/tc/reference/comparison-of-official-group-… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[nova] FFU : When should we remove reshape support for a feature ?
by Sylvain Bauza 31 Mar '20

31 Mar '20

Hola, In Stein, I provided a new feature [1] that was checking inventories from multiple children resource providers (RP). Since in Rocky, those inventories were only on the root RP, I had to provide both : #1 : an upgrade support for RPs that were not having a parent RP (that was the case of Stein compute nodes) [2] #2 : a reshape method in the libvirt driver for moving allocations from a root RP to children RPs [3] Now, we're in the Ussuri timeframe and as I was usually doing, I removed the upgrade support (in #1) since we're 100% sure that all compute nodes are either Train or Ussuri [4] This is cool, but now the reshape code I wrote for #2 no longer works (which is normal, since the 'non-Stein' support was removed) [5] Soooooo. Can I also then remove the reshape support ? That would mean that upgrading from Rocky to Train would work, but Rocky to Ussuri wouldn't. I'm personally OK with this, but I guess other people could have concerns with. Do we have any consensus about how longer we would support a reshape ? I think honestly that a 3-releases time window is enough but I can hear some disagreements about this strawman proposal. If so, please voice. -Sylvain [1] https://blueprints.launchpad.net/nova/+spec/vgpu-stein [2] https://review.opendev.org/#/c/636591/ [3] https://review.opendev.org/#/c/599208/ [4] https://review.opendev.org/#/c/715489/ [5] https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackc…

3 3

[all][elections][ptl][tc] Conbined PTL/TC Nominations Last Days
by Ian Y. Choi 31 Mar '20

31 Mar '20

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Mar 31, 2020 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2020-03-24 23:45:00 UTC Nominations end @ 2020-03-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 9:22:53 Nominations progress : 94.42% --------------------------------------------------- Projects[1] : 60 Projects with candidates : 30 ( 50.00%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 30 (Adjutant Barbican Blazar Cloudkitty Congress Cyborg Designate Freezer Heat I18n Infrastructure Karbor Loci Magnum Manila Masakari Nova Octavia OpenStack_Charms Oslo Packaging_Rpm Placement Quality_Assurance Rally Requirements Searchlight Swift Tacker Tricircle Zaqar) =================================================== Stats gathered @ 2020-03-31 14:22:07 UTC This means that with approximately 2 days left, 30 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[kolla] Tomorrow's meeting cancelled
by Mark Goddard 31 Mar '20

31 Mar '20

Hi, I'm on leave tomorrow and several cores are unavailable so let's skip this week's meeting. Please bear in mind we're approaching OpenStack feature freeze, and our own freeze will follow shortly afterwards. As such, please focus on finishing off and reviewing our cycle priorities. Cheers, Mark

1 0

[qa] Not running for PTL
by Ghanshyam Mann 31 Mar '20

31 Mar '20

Hello Everyone, I would like to announce that I am not running for QA PTL for V cycle. Its been 4 cycles for me as the QA PTL and I think it's time for a new leader to take this responsibility. It has been a great experience for me as PTL and keeping the QA program healthy and active as it was from starting. Stabilizing the testing more and adopting new tooling under QA. Apart from PTL role, I will continue my contribution to QA with the same bandwidth as it is now. There is no change in that and you can keep pining me for any issue or discussions. Also, I will be there for a smooth PTL transition. Thanks everyone for making these 2 years a great learning period for me. -gmann

2 1

[election][heat] PTL candidacy for Victoria
by Rico Lin 31 Mar '20

31 Mar '20

Hi all, I would like to announce my candidacy for Heat PTL for Victoria cycle. Over the past couple of cycles, we running Heat dynamically according to requirements. We never stop encouraging people to join us and provide consistent reviews or fixes as much as we can basic on priorities. And if those priorities not working for you, that means you must join the community to help. I believe the goals for the next cycle should be community CI stability, cross-project/community scenario tests to ensure what we deliver to users will get higher quality and container-native support to make sure we provider useable Orchestration services for container environment. I believe in new features, so we will try to encourage more features and review them as many as possible, but will not plan for team feature goals unless we can trigger more discussion and hands-on.Thank you for taking my self-nomination into consideration. Rico Lin -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[election][kolla]
by Mark Goddard 31 Mar '20

31 Mar '20

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Victoria cycle. I have been PTL for the Train and Ussuri cycles, and would like the opportunity to continue to lead the team. I am pleased with the current state of the project. We have an active community, produce interesting and useful features, and regularly receive positive feedback. The Kolla community has always been notable for being vendor-neutral and operator-driven. I recently made a proposal for a Kolla --SIG-- Club [1] with the aim of improving communication between regular contributors and the wider community. We had a good response, and I'm looking forward to seeing how it progresses this cycle. If elected this cycle I'd like to encourage continued work on some familiar themes - improving sustainability, increasing test coverage, and better integrating Kayobe [2]. I'd also like to see us focus on our documentation. Thanks for reading, Mark Goddard (mgoddard) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013122.ht… [2] https://docs.openstack.org/kayobe

3 2

[Murano-Open-PaaS] Openstack using guacamole
by Roman Gorshunov 31 Mar '20

31 Mar '20

Hello Samuel, Thanks for your email. Yes, Guacamole can be installed as an app via Murano. Discussions about Open PaaS are now in openstack-discuss mailing list. Please use the tag [Murano-Open-PaaS] in the subject line. I'm re-routing your email. Here are docs for the Murano project [0]. [0] https://docs.openstack.org/murano/latest/ Best regards, Roman Gorshunov On Thu, Mar 26, 2020 at 4:37 PM Samuel Abdullah <samuel(a)silverliningsys.com> wrote: > Hi, > > Would like to ask if it is possible to run guacamole in openstack > environment? > Seek for help on how would this be possible as i saw that guacamole > component are part of the openstack in your murano project > > Looking forward for your reply > > Best Regards > > -- > > <https://www.silverliningsys.com/> > > www.silverliningsys.com > > > *Abu Bakar Samuel Abdullah* > > Cloud Infrastructure & Operations > > > P: +603-2712-0081 > > M: +60.12.654.5938 > > E: samuel(a)silverliningsys.com > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

3 4

[tc][elections] Nomination
by Belmiro Moreira 31 Mar '20

31 Mar '20

Greetings, I'd like to announce my candidacy for the OpenStack Technical Committee (TC). I'm involved with OpenStack since 2011 when CERN started to investigate a Cloud Infrastructure solution. I work in the design/deployment/operation of the CERN OpenStack Cloud. My particular interest has been how to scale and operate large OpenStack deployments. I was an active member of the old Large Deployment Team (LDT), a group of operators that shared ideas on how to scale OpenStack. I had the privilege to learn from a talented group of Operators on how they manage/run their infrastructures. Currently, a new group was created (Large Scale SIG) where I continue to have an active role. I'm fortunate enough to have attended most of the OpenStack Summits since San Francisco (2012). I'm a regular speaker talking about my experience operating OpenStack at scale. Also, I serve regularly as a track chair, participated in few OpenStack Days, Ops Meetups and wrote several blog posts. During the last year I served as a member of the OpenStack User Committee (UC). We focused in the Ambassador Program revamp and SIGs support. If elected I will focus to engage the Operator/Users community with the different Development teams and bring my experience as Developer/Operator to the group to help in the oversight on all the technical matters. It would be an honor to be an advocate of this great community and promote its mission. Thank you for your consideration, Belmiro Moreira

1 0

Add Masayuki Igawa candidacy for Quality_Assurance
by Masayuki Igawa 31 Mar '20

31 Mar '20

Hi everyone, I'd like to announce my candidacy as the PTL for the Quality Assurance PTL role for the Victoria cycle. First off, I would like to thank you all the contributors, core reviewers, PTLs, and anyone who involves and makes the OpenStack better. Let me introduce myself briefly. I have joined the OpenStack community since 2012 as a developer. Now, I'm a core member of some QA projects such as Tempest, os-testr, OpenStack-health, stackviz, coverage2sql, subunit2sql[1]. And I also played the mentors/instructors role at the upstream training in Japan several times. It was a great experience to know how difficult of telling people how OpenStack community is going. In the Ussuri cycle, we've almost completed "Drop Python 2.7 Support"[2] which is one of the Ussuri goals. We also have been trying to keep the gate stable which is the mission of the team. And we approved one interesting spec - "Whitebox Tempest Plugin"[3] which is one of the tempest plugins. It can access controller nodes and/or compute nodes such as read and write INI files, restart services, examine the database, etc. Tempest does not cover this feature because it isn't the scope. However, it is necessary to expand automated testing. We still have a few more planned work pending for Ussuri, such as removing/ migrating the .testr.conf to .stestr.conf, RBAC testing, removing tempest plugin sanity BLACKLIST, adding new glance tests, improving Tempest cleanup, etc. But I think we will be able to accomplish them in the Ussuri cycle as we still have around one month for Ussuri release. Along with daily QA activities, my priorities for QA for the next cycle will be: * New ideas for more tooling and/or tests project to focus on OpenStack or common communities. (whitebox tempest plugin, for example) * Stability of Tempest plugins. The sanity job is already voting, and there are 57 tempest plugins[4], but 12 plugins are in the blacklist. Some of the plugins are deprecated already, but it's hard to know from the registry page. It needs to be classified, and the page can be improved. * Guiding and motivating more contributors to QA projects, improving documentation, and advertising OpenStack QA projects. * Completing Ussuri priority items if it's still lasting. It's hard to accomplish without our collaboration. So, let's do it together! [1] http://stackalytics.com/?user_id=igawa [2] https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html [3] https://specs.openstack.org/openstack/qa-specs/specs/other/whitebox-tempest… [4] https://docs.openstack.org/tempest/latest/plugin-registry.html#detected-plu… Thanks for your consideration! -- Masayuki Igawa (masayukig)

1 1