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 15 Jun '20

15 Jun '20

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

10 22

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

26 May '20

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

5 9

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

24 May '20

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

3 5

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

22 May '20

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

2 1

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

14 May '20

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

2 2

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

14 May '20

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

5 6

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

08 May '20

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

2 1

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

07 May '20

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

2 2

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

05 May '20

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

6 9

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

01 May '20

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

9 16

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

30 Apr '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 22 Apr '20

22 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 10 Apr '20

10 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 08 Apr '20

08 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 07 Apr '20

07 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 07 Apr '20

07 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 06 Apr '20

06 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 06 Apr '20

06 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 01 Apr '20

01 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 01 Apr '20

01 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 31 Mar '20

31 Mar '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 31 Mar '20

31 Mar '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 31 Mar '20

31 Mar '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 31 Mar '20

31 Mar '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 31 Mar '20

31 Mar '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 30 Mar '20

30 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

[election][manila] PTL candidacy for Victoria
by Goutham Pacha Ravi 30 Mar '20

30 Mar '20

Greetings Zorillas & other Stackers, I would like to submit my candidacy to be the PTL of Manila for the Victoria cycle. I stepped up to this role for the Ussuri cycle and have had a tremendous learning experience. I achieved numerous things I set out to do with the support and encouragement of my fellow contributors. I'd like to continue in this role and drive the growth of this project and its community. In my role as the liaison for this community, I was able to effectively aid internalizing the "OpenStack way" of development. The project and its many deliverables saw several new contributors in the Ussuri cycle. This included successful Outreachy and Google Summer of Code interns who continue to contribute beyond the completion of their internships. We were able to prune the core maintainers group to active reviewers while mentoring and adding three new individuals. We also had a significant reduction in our bug backlog, while we continue to farm out issues for potential first time contributors. In the Victoria cycle, I plan to continue on this mission of growing the contributor base, and having Manila be a great on-boarding project for the OpenDev community. In the Ussuri cycle, thanks to our Outreachy interns, their mentors and the reviewers, we merged feature functionality to support the OpenStack Client. Similar velocity was achieved in the manila-csi project through the GSoC internship program and the continued investment beyond. We didn't get much merged in the Ussuri cycle in terms of improving the availability and fault tolerance of the core share-manager service. These multi-cycle work items will remain a matter of focus and I'd devote time to drive these further. The Ussuri cycle also saw reducing feature parity between the DHSS=True and DHSS=False driver modes. This was a goal for this community for several releases and it's coming to fruition through vendor-agnostic community driven design. In Victoria, we plan to continue down this patch and eliminate further feature gaps between many deployment and usability choices with Manila. As PTL, I will drive the community through the OpenStack-wide goals during the Victoria cycle, alongside some of our own: - Graduating experimental features: We have had significant soak time for all three features (Share Replication, Share Migration and Share Groups); and we have begun the steps to take them out of their experimental state. - Apply for the "vulnerability-managed" TC tag: As a community, we worked through our first CVE in Ussuri cycle with the aid and support from the OpenStack Vulnerability Management Team. In the Victoria cycle, we'll drive to achieve this TC tag for the project. - Evolve bug triage criteria, and automate it: Seeing an unmanageable number of bugs is a distraction enough to ignore the bug backlog. As a community we discussed the idea of automating some triage tasks on our backlog. - Address testing gaps: We'll continue to add new test case scenarios and address gaps such as the lack of scenario testing for the cephfs-native protocol. While this goal may not have a definition of done, it is here to convey my intention to prioritizing regression testing on par with feature development. So, if you will have me, I wish to serve through Victoria and get things done. Thank you for your support, Goutham Pacha Ravi <gouthampravi(a)gmail.com> IRC: gouthamr [1] https://review.opendev.org/#/c/716107/

1 0

[all] Virtualized PTG Brainstorming Community Meetings
by Kendall Nelson 30 Mar '20

30 Mar '20

Hello Everyone! So! After Marks initial email[1] that announced we would be virtualizing the PTG and collected volunteers[2] to help brainstorm the best way to hold the PTG virtually, we polled the volunteers for the best times to meet. In trying to be the most inclusive we have settled on three meetings to brainstorm together as a community. They are as follows: - April 2nd at 12:00 UTC - April 6th at 17:00 UTC - April 7th at 2:00 UTC We will be using my zoom[3] and continue using the same etherpad [2] that we collected volunteers in for all the notes from all three meetings. All are welcome! And if you can attend more than one meeting, please do! The more overlap we have the more cohesive discussions we will have. Hope to see you all there! -Kendall Nelson (diablo_rojo) [1] http://lists.openstack.org/pipermail/foundation/2020-March/002854.html [2] https://etherpad.openstack.org/p/Virtual_PTG_Planning [3] https://zoom.us/my/diablorojo

1 0

review.opendev.org Downtime March 20, 2020 at 1400UTC
by Clark Boylan 30 Mar '20

30 Mar '20

Hello all, The OpenDev team is planning to take a short downtime March 20, 2020 from 14:00UTC to 15:00UTC. This outage will enable us to rename a few projects and redeploy Gerrit using containers. The container based deployment is an important first step in our longer term plan for upgrading Gerrit to a modern version. We recognize that this will be a disruption during an already disrupted week for many. We feel this is worthwhile as it fits into project release schedules and sets us up well for the future. Thank you for your patience. Feel free to ask us any questions you may have on this thread or in #opendev on Freenode. Clark

4 5

[first contact][all] Meeting Frequency & Time
by Kendall Nelson 30 Mar '20

30 Mar '20

Hello Everyone, In our meeting yesterday[1], the first one of the year, we discussed changing our meeting frequency to once a month and maybe shifting the day/time. I think Tuesday still works for me but an hour or two earlier wouldn't go amiss. If no-one objects to this, I will put a patch up to change the meeting time & frequency next week to monthly instead of biweekly and -Kendall (diablo_rojo) [1] Meeting Log: http://eavesdrop.openstack.org/meetings/fc_sig/2020/fc_sig.2020-03-25-02.39… [2] Current Meeting Info: http://eavesdrop.openstack.org/#First_Contact_SIG_Meeting

1 1

[ironic][ops] Breaking change coming in the Victoria development cycle
by Julia Kreger 30 Mar '20

30 Mar '20

Greetings everyone, One of the items the ironic team has been focused on is improving security of remote/edge deployments where machines may be deployed on networks where an un-trusted actor could also be present. Our answer to this has been the concept of utilizing a temporary token[0] for the deployment, which we use to validate the agent heartbeat operations, and commands sent back to the agent ramdisk from the conductor. While not a complete solution to all possible attack vectors, it is a step forward and we will be taking more steps during the next cycle. For the Ussuri release, this functionality is always enabled, but is not explicitly required[1]. Deployments, with older ramdisks who choose to require this capability, must update their deployment/rescue/cleaning ramdisks to a version with a newer ironic-python-agent version from Ussuri development cycle. In Victoria, the ironic team will change the default for requirement of agent tokens such that they are required by default. Pre-Ussuri agent ramdisks will no longer work and will need to be updated. Please let us know if you have any questions or concerns. -Julia [0]: https://docs.openstack.org/ironic/latest/admin/agent-token.html [1]: https://docs.openstack.org/ironic/latest/admin/agent-token.html#how-it-works

2 1

[elections][ironic] PTL candidacy for the Victoria cycle
by Julia Kreger 30 Mar '20

30 Mar '20

Greetings my OpenStack family! I realize we are presently in a stressful time. That each of us are worrying, and that many of us are struggling. "Normalizing", and ultimately accepting the things we cannot control is a vital step forward in our personal and community growth. Finding a path forward is critical in this time. Not just as humans in a pandemic, but as also community members in a project. The vital aspect is continuous across both contexts: We cannot do it alone, We must work together! I too have strengths and weaknesses that I am all too well aware of, and there truly is nothing more re-assuring than those around you encouraging you to continue to support them. For we all need sturdy foundations to take the steps forward. To build the next layer! To continue the journey we are on. As such, I hereby announce my candidacy for the role of Project Team Leader for the Ironic project during the Victoria cycle. That is if you will have me. I foresee the upcoming cycle as a time when we will need to be there to support our community and users. This may take the form of advanced features, lending an occasional ear, or going that extra mile to help each other. And if we need a distraction, I believe we have have some difficult problems yet to solve which can have a major impact in not just our code, but the world at large. While not an exhaustive list of items, it is still an impactful list of work we have been discussing and seek to add into Ironic moving forward. * Multi-tenancy, while underway, opens the world to new possibilities and co-ordination of hardware resources with-in an organization or even across organisations. * Persistent Agents allowing for faster re-provision of deployments on the edge and where the networking is in a fixed configuration. * TLS for Agent Communication to help ensure the nodes on the edge remain secure. * kexec could potentially save significant amounts of time between steps of deployment, and enable operators with larger memory footprints to save precious time of a Power-on-Self-Test. * Attestation system integration so we can improve the odds of identifying a machine with modified firmware and prevent it from moving through the hardware life-cycle as a result. * Enhancement of power management, so operators can avoid having to wait for the Power-on-Self-Test, and maybe even power some of those machines off. Onward, together! For I'm fairly sure we've not completely taken over the world... yet. Julia (TheJulia) Kreger

1 0

[ptl][tripleo][election]
by Wesley Hayutin 30 Mar '20

30 Mar '20

Greetings, I would like to propose my candidacy for the TripleO PTL role in the Victoria cycle. This cycle there has been a lot of progress in simplifying the TripleO code base and the steps in the deployment. The team should be very proud about migrating from mistral to ansible, novaless deployment, the creation of tripleo-operator-ansible, removing paunch, and container improvements. We were also able to migrate Ussuri jobs from CentOS-7 to CentOS-8 in the nick of time. Like in the Ussuri cycle I would like to see the project continue to focus on simplification and improving the user experience. * Continue to push forward with tripleo-ansible and the transformation squad. * Work with ansible sig group, kolla, openstack-ansible, tempest and related projects. * Continue to simplify the stack of components where possible to achieve a faster, better and more efficient deployment. * Mature new features like tripleo-operator-ansible. * I would also like to focus on encouraging the project's more recent contributors to take a larger role in active collaboration, participation and leadership. Thank you for the opportunity! https://review.opendev.org/716077

1 0

[oslo] Feature Freeze exception request
by Alan Bishop 30 Mar '20

30 Mar '20

I'd like to request an exception for https://review.opendev.org/710539. CI is fully green now, it has one +2, and an early patch set had +2 from another reviewer. Thanks for your consideration, Alan Bishop (abishop)

2 1

[tc][elections] my nomination
by Jeremy Freudberg 30 Mar '20

30 Mar '20

Hello everyone, I hereby announce my candidacy for the OpenStack Technical Committee. If you don't know me already I'm the guy who proposed that OpenStack releases be named after ATCs[0]. Some people thought my proposal was satire, but it wasn't, so if you're hoping to elect a satirist look elsewhere. However, this incident is part of my motivation to run for the TC. We can't have satire without culture, and clearly our community has a strong culture if we suspect, and even hope, that satirists are lurking about. All of this indicates to me that OpenStack is a special place and so I would like to play a role in the success of that special place by serving on the TC. "Immensely qualified" is the opposite of what I am, but I have some strengths: * I am nosy. * I have touched a lot of areas of OpenStack because Sahara touches a lot of areas of OpenStack. * I understand the struggles of working on a minor project (tiny team and limited audience but still big goals) because Sahara is a minor project. * I am an optimist because optimism is a necessary part of being the PTL of Sahara nowadays. * I am young. I have much to learn, and luckily I love learning. I don't have many specific goals other than making our community as vibrant as possible. Out of vibrancy, good software will hopefully come naturally, in order to make OpenStack the best it can be in the current landscape. For me being a TC member would be mostly about facilitating the exchange and synthesis of ideas (perhaps crazy ones) and not so much about being a source of ideas myself. Of course, if I happen to have a good idea (they tend to strike very suddenly), I'll share it! To close, thanks to all of you for making our community what it is. It is really something special and everyone who I have ever interacted with (or merely spied on) has been such a delight in their own unique way. It would be an honor to serve you all. -Jeremy [0] https://review.opendev.org/#/c/677827/

1 0

[election][plt] Sean McGinnis candidacy for Release Management PTL
by Sean McGinnis 30 Mar '20

30 Mar '20

Hello everyone, I'd like to run for PTL of the Release Management team again. We have a lot of great automation in place in the releases repo to handle a lot of the release process with, hopefully, minimal overhead. That said, we've made some process changes over the last couple of release cycles that have placed a little more work on the release team's shoulders. We have a lot of these processes mostly automated, but a few things that require a little history and trival knowledge yet. Over the next release cycle I would like to work towards automating a little more of that to make sure if/when anyone else steps into a release manager role, it will be an easy introduction to them to follow our release process documentation and have tooling in place to execute each step without needing to have a very deep understanding of how all the various pieces fit together. Like other projects, we've lost some people, or some of us are not able to spend as much time as we used to on the project. But we've also picked up some great help too. Anything we can do to help anyone to join the team and know what to do and how to do it will be better for us all. Thanks for your consideration! Sean

1 0

[election][tc] Nomination for TC
by Graham Hayes 30 Mar '20

30 Mar '20

Hello Everyone, I have been a member of the TC for 2 terms now, and I am running again for another term on the TC. I have been involved in OpenStack as a developer, operator, PTL, and TC member for a long time, and I think that I can continue to contribute to the community on the TC. I worked as the technical lead for the System Operations team in Verizon Cloud Platform, where we ran 90+ OpenStack installs across the world, ranging from 3 compute micro regions where we needed edge style compute, to much larger footprints for core regions in the US. This gave me a unique viewpoint on how people use OpenStack for both small scale, and for large, real time mission critical telecommunications applications. Further back in my career, I was part of a team that ran the DNSaaS service in HP Cloud (based on Designate of course), which combined with my current role in Azure, where I am looking at how people use both on prem and external clouds, gives me a good insight into the needs of a cloud provider. My main focus over the last term has been trying to get a co-ordinated way for organizations to contribute to OpenStack - Graham's soap box at the Board face to face meetings has become a regular event. Thankfully, I think this has helped push this forward, and I know I have seen people getting involved in the projects I keep an eye on. I have also been involved in the design discussions around `Project Teapot`_ which I think is a great way for OpenStack to help people scale and manage their data centers, while providing the services modern applications are starting to use. I firmly believe that something like Teapot is an important focus of development for OpenStack. I think the new `ideas repo`_ is a fantastic idea and encourage people to put what ever they think is a good idea for OpenStack in there. I will definitely be putting up some of the ideas I have talked about over the years in there. As a long time PTL of a project I know the pressures they can be under and can provide insight as we consider the future governance of the OpenStack project, and its sub projects. This has given me a lot of historical knowledge and context to why some things within our community are the way they are, and as we record this to avoid needing something as unreliable as a human brain (rst is a lot better :) ) I feel I can contribute to the discussion. Finally, I feel that over the years I have made it clear that I will speak out even if I know it will cause push back, and this has allowed me to receive frank and honest feedback from people in community who don't always wish to spend the mental energy, or pay the social tax of raising topics that can be controversial. I don't plan on changing this. Lastly, I have really enjoyed working in this community, it has given me a lot both personally and professionally, and I feel that I can still pay that back. If you agree, please vote for me in the up coming elections, if not please ask me questions in the next week or so, but for everyone, please vote for whoever you think will be the best for OpenStack. Thanks for taking the time to read this, - Graham .. _Project Teapot: https://governance.openstack.org/ideas/ideas/teapot/index.html .. _ideas repo: https://opendev.org/openstack/ideas

1 0

[oslo] Feature Freeze is this week
by Ben Nemec 30 Mar '20

30 Mar '20

Apologies for not mentioning this in the meeting this week, but Oslo Feature Freeze is already this Friday.[0] After Friday, anything that is not a bug fix will need a feature freeze exception in order to merge. If you're wondering why Oslo freezes early, there's a doc[1] for that. If you have any questions not answered there, feel free to reply here or ping me on IRC. Thanks. -Ben 0: https://releases.openstack.org/ussuri/schedule.html 1: https://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freez…

1 1

[elections][tc] Nomination
by Nikolla, Kristi 30 Mar '20

30 Mar '20

Hi all, Please consider my candidacy for a seat on the OpenStack Technical Committee. I'm a software engineer at the Mass Open Cloud[0], a collaboration between the five major universities of the Boston area to create and operate a public cloud that can be replicated and federated. I've been involved with OpenStack for the past 5 years as a user, operator, and developer. I'm a core reviewer for the keystone project, and I'm also running for its PTL for the Victoria cycle[1]. I have a previous unsuccessful run for the TC[2]. Lately, I've also been involved with OpenInfra Labs[3], a new project of the OSF. I do not have a platform per se, and honestly I wasn't planning on running at all. I have a lot to learn, and if I were to be elected, pretty big shoes to fill. If you are looking for someone that already has all the answers, look elsewhere. On the other hand, if you're looking for someone who is eager to grow, learn, and give back to the community in any way he can, I hope you will consider my candidacy. I'm deeply grateful to the OpenStack community and all the people I've had the pleasure of working with, being mentored by, and doing karaoke during the PTGs. You are like family. Thank you, Kristi Nikolla Pronouns: he, him, his [0]. https://massopen.cloud [1]. https://opendev.org/openstack/election/raw/branch/master/candidates/victori… [2]. https://opendev.org/openstack/election/raw/branch/master/candidates/stein/T… [3]. https://openinfralabs.org

1 0

[election][storlets] PTL candidacy for Victoria
by Takashi Kajinami 30 Mar '20

30 Mar '20

Hi All, I'd like to announce my candidacy to run PTL role for Storlets project in the next Victoria cycles. Thanks to the great effort by several members, we've completed all python3 compatibility work during this Ussuri cycle. Because we are a really small team now, I'll expect that we will focus on improving operability and maintenability in this cycle, while we will also discuss how we'll keep our project in the future. Managing that development and discussion is my responsibility in Storlets project. Thank you, Takashi Kajinami

1 0

[LOCI] Failed to build Trove image
by Lingxian Kong 30 Mar '20

30 Mar '20

The command I am using: docker build . \ --build-arg FROM=loci-base:ubuntu \ --build-arg PYTHON3=yes \ --build-arg PROJECT=trove \ --tag loci-trove:ubuntu The error: http://paste.openstack.org/show/791311/ Then I changed pydep.txt: uwsgi [!trove] and ran again, another error occured: http://paste.openstack.org/show/791313/ However, if removed '--build-arg PYTHON3=yes' in the command (even without modifying pydep.txt), the image could be built sucessfully. Does LOCI support to build Python 3 image or I did something wrong? - Best regards, Lingxian Kong Catalyst Cloud

1 0

[tripleo][nova] New project to support advanced Nova features in TripleO
by Piotr Kopec 30 Mar '20

30 Mar '20

Hello, I'd like to introduce a new project and repository [0] that is intended to host Ansible roles to support advanced Nova features, such as FPGA or NVDIMM. Roles will be as generic as possible but the main use case is to use them with TripleO. This project is intendent to be managed similarly to `tripleo-ipa` [1]. Please, accept the change to add new project and repo. Best regards, Piotr [0]: https://review.opendev.org/#/c/715734/ [1]: https://review.opendev.org/#/c/711114/

1 0

[all][tc] Post-mortem of my time on the TC
by Zane Bitter 30 Mar '20

30 Mar '20

As promised last year, I will not be running for a third term as a member of the Technical Committee. I'm stepping down to spend more time with my family (no, really! ;) I thought this would be a good opportunity to talk to those folks who are thinking of running for a seat, or who aren't but should be. The most common question I hear from potential candidates is "what should I actually do on the TC?" I can't tell you what *you* should do, but I can tell you what I did and how that worked out. Maybe that will give you the flavour. And perhaps (he hinted) some of the other outgoing TC members can do the same to provide more of a cross-section. * I drafted and edited the review guide, "How to Review Changes the OpenStack Way", to try to ensure that the best parts of our review culture are evenly distributed across the project: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html (This started as part of an initiative from Julia Kreger to reduce nitpicking in reviews.) In theory anybody could have done this, but in practice I think this is one of those things that only somebody elected to the TC could have driven. I received a lot of feedback afterwards (which is unusual for anything the TC does): several people, and one whole team, mentioned that they had tweaked their reviewing style after this discussion. And hearing their feedback prompted me to tweak my own reviewing style as well. * I drafted and edited the Vision for OpenStack Clouds: https://governance.openstack.org/tc/reference/technical-vision.html. This was a ton of work as it involved consulting with so many people: first, folks in the community who on the surface appeared to have quite different visions for what OpenStack should be, who later turned out to not be so far apart as we all thought. After a lengthy round of reviews, I approached every project team individually to explain the specific relevance to them, and seek their feedback. Finally, I presented it to the OSF Board and held an in-person feedback session at the Forum, after all of which it was approved by the TC. I have some mixed feelings about the success of this. I still believe it was desperately needed... in about 2013. Now the Kubernetes community is succeeding at engaging with actual end users (not just operators), which OpenStack has always failed to do. With contributions to OpenStack dropping, it's not clear that we can, or necessarily should, sustain such a broad vision. It is my hope that if and when the community needs to discuss adjusting our scope, we will do so by amending this document - going through it section by section and deciding which parts to double down on and which to allow to fall by the wayside - and not by a series of ad-hoc actions that leave everybody confused as to what the project is supposed to be once again. On a personal level, the vision has been extremely valuable for me because it required me to spend a lot of time thinking deeply about the various components of OpenStack and how they fit into a greater purpose. A large portion of the value comes from participating in the process, not necessarily the final document. I hope that all of the folks who helped along the way got as much out of it as I did. * I developed the process by which we keep OpenStack up to date with new releases of Python: https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… I also shepherded it through the first couple of release cycles, to try to entrench it as a standard part of each release. (BTW this task needs somebody to take it over.) This mostly involved pointing people back to the resolution and inviting them to formally update it every time someone tried to bikeshed the details, which happened more than I ever believed possible. (To date there have been no changes proposed to the resolution.) * I engaged with the OSF Board to pass on feedback from members in the developer community on the process for adding new Open Infrastructure projects (e.g. Zuul, StarlingX, Airship, Kata). Sometimes the work of the TC is completely invisible! I also tried to convey information the other way, publicising information that was otherwise only available by attending board meetings. (Most TC members usually attend board meetings, including the in-person joint leadership meetings held before Summits.) * In response to feedback from the board, I replaced the "Help Most Wanted" list with the "Upstream Investment Opportunities" list, and kick-started the rewriting of the existing entries in a format that is more targeted at decision-makers: https://governance.openstack.org/tc/reference/upstream-investment-opportuni… (Huge thanks to Tom Barron, who did even more work to complete the job of converting all of the existing entries - proof that you don't need to be a TC member to start contributing to governance activities.) It remains to be seen whether this will have any effect, but this content is now being shared in the community newsletter, and the board is making moves to use it to actively solicit contributions to the community. Previously they felt unable to make use of the Help Most Wanted list because it was written with the wrong audience in mind. * I tweaked the guidelines for the release naming system to better align with our actual practice, because they had diverged somewhat. Believe it or not, this one issue took up more of the TC's time than any other thing that happened in 2019, and I'm very glad that we ended up not needing these tweaks because we eventually replaced the process wholesale, with one that makes it explicit that the TC is ultimately accountable for the release name not causing any international incidents or other snafus. * I researched and documented a design, developed during extensive discussions with many members of the technical community, for a new kind of simplified cloud built partially using OpenStack components but designed to be Kubernetes-native first: Project Teapot https://governance.openstack.org/ideas/ideas/teapot/index.html I do think this is worth building, but if nothing else I really hope this helps bring into focus the parts of OpenStack that remain essential in a Kubernetes-centric world. In writing this I was very much guided by the Vision for OpenStack Clouds as well as the ways in which Kubernetes expects to interact with an underlying cloud. I think we need more of these kinds of exercises, and while they don't have to be sponsored by TC members, I think it helps. If there's a pattern here it's this: take something that's implicitly agreed upon by the community (whether we realise it or not), write it down, seek feedback, and make it explicit so that anyone can refer to it, rather than leaving it as closely held tribal knowledge. Of course it goes without saying that I was involved in many more discussions and reviews that were led by others. I'll leave it to them to talk about those. And it should also go without saying that all of the work listed above was greatly improved by the input of the many talented folks in our community who contributed. In my humble opinion OpenStack is the best open source community of its size ever created. That's because we believe not just in one 'open' (source), but four (https://governance.openstack.org/tc/reference/opens.html) because we're committed to using open tools to build open software; and because, while it's certainly not the case that we can't improve, we have managed to do this while avoiding a widespread culture of bullying. To do all of this on the scale of OpenStack was, as far as I know, completely without precedent. (Perhaps the ASF comes closest, but its projects operate independently, unlike OpenStack subprojects.) All of us should be proud of this achievement. But it didn't happen by accident: it is the product of concerted effort by leaders in our community over the course of a decade. It's been a tremendous privilege to work alongside some of those folks, both before, during and (hopefully) after my time on the TC. I have learned so much from them. Now it is time for others to step up and continue to build that legacy, as the project evolves and adapts over time. The diversification of the OSF also gives us the opportunity to spread our ethos to other projects under the same umbrella, and from there to the open source community as a whole. However, we must remember that having a great community is not enough. To remain relevant, we also need to produce software that meets users' needs, which change over time. By an accident of fate I have approached OpenStack from a different direction than most - I came to OpenStack via the Heat project, which means I've always looked at it from an outside-in standpoint: users are building cloud applications, how can OpenStack provide them with what they need from a cloud through an open API? Many others, by necessity, have approached it from the inside-out: we have all this hardware, how can we expose its capabilities to users? I think it is fair to say that many of these folks and I have found each other's views to be mutually incomprehensible over the years. In writing up the Teapot design, I have learned a lot more about the other perspective. I believe we will need a more people to also grow their understanding in the opposite direction to avoid the trap of most capital-E "Enterprise" software - designed to check the boxes of those who decide what products to buy, but widely hated by all those forced to actually use it. Future TCs will have to grapple with this because nobody else in the community is really empowered to do so. The openstack/ideas repo that JP created is a great place for anybody to start documenting ways that we can improve. For my part, this is not goodbye. However, I have already been splitting my time between OpenStack and metal3.io and I expect that the drift in the other direction will only accelerate now that I no longer have any formal responsibilities here. Please feel free to contact me or ask questions if you think I can help. Stay safe out there, and by "out there" I mean physically isolated in your own homes for the next little while. cheers, Zane.

5 4

[mistral][ptl][election] PTL candidacy for Victoria
by Renat Akhmerov 30 Mar '20

30 Mar '20

Hi, I'm Renat Akhmerov. I'd like to announce my PTL candidacy for Mistral in Victoria cycle. In Ussuri, we kept improving Mistral performance to address use cases that desperately needed it. For the most complex known workflows the execution time has now dropped by 5-6 times. Besides lots of performance changes we also achieved: * Restructured the documentation completely * Fixed a number of documentation pages and added several new ones. There's still a lot to do on that though. * Made a big refactoring of Mistral actions and moved all OpenStack actions into mistral-extra repo. * Added namespaces for actions and workbooks * Added a new cookiecutter-based template for creating Mistral action projects. * Fixed a number of important bugs (for "join" tasks, scheduler etc.). * And lots of other changes.. For V cycle I'd like to keep making Mistral more usable: * Consistent and well-structured documentation * More ways to create Mistral actions (including action providers) * Additional tools that simplify creating custom actions and functions for Mistral * Easier debugging of workflow errors * Easier and smoother installation process We're already making a good progress with all that and anybody who wants to participate is very welcome onboard. The best way to get in touch with us is IRC channel #openstack-mistral or the openstack-discuss mailing list (with [mistral] tag in email subject). [1] https://review.opendev.org/#/c/715837/ Thanks Renat Akhmerov @Nokia

1 0

[election][glance] PTL candidacy for Victoria
by Abhishek Kekane 29 Mar '20

29 Mar '20

Hi All, I would like to announce my candidacy for Glance PTL for the Victoria cycle. Over the past couple of years we've had a small team looking after Glance and planned the priorities accordingly. During Ussuri cycle we were able to add a couple of important features related edge computing, plugin for image decompression, restored s3 driver support in glance-store, removed deprecated sheepdog driver and fixed some important bugs. Should community to select me as PTL for Victoria cycle I would keep driving the key priorities. Production stability, finishing the work we've had in flight and focus on the feature needs related to Edge computing. Thank you for taking my self nomination into consideration, Abhishek Kekane (abhishekk)

1 0

[election][cinder] PTL candidacy for Victoria
by Brian Rosmaita 29 Mar '20

29 Mar '20

Hello everyone, I would like to announce my candidacy for Cinder PTL for the Victoria cycle. Given that I'm the current PTL, you already have a pretty good idea of what things will be like on the Cinder project with me in that role and whether or not it would be a good idea for me to continue. So instead of bribing you with campaign promises, I'd like to take this opportunity to look at the current state of the project and what things look like for the Victoria cycle. The Cinder community remained fairly stable from Train to Ussuri, which was great in these downsizing times. Some of the drivers that were marked 'unsupported' for the Train release have been restored to 'supported' status during the Ussuri cycle. Some, however, have not. We relaxed the removal policy to give vendors more time to address CI issues and to make it easier for operators using such drivers. We'll see during the Victoria cycle whether this actually encourages the vendors of drivers that have been declared 'unsupported' to get their third-party CIs running again and having the drivers reinstated. During Ussuri, the team gained more testing expertise, particularly around creating more scenario tests, though this hasn't been reflected yet in committed code. As we get more scenario tests into the cinder-tempest-plugin, we'll be able to catch more bugs that affect multiple drivers, whereas now what mostly happens is that driver maintainers fix these piecemeal as they become aware that they affect their drivers. Thus, increasing the scnario test coverage will continue to be a focus in Victoria. The virtual PTG that we held as a follow-up to the Shanghai PTG was productive, as were the two virtual mid-cycle meetings we had this cycle. So I think we're in good shape to make the most of the fully virtual Victoria PTG. I think as a community, we're all doing good work on the Cinder project. We've got cinderlib to keep us relevant in a container-oriented world, and I think we're doing a solid job keeping the software stable and reliable. I'm sure the driver maintainers would like to see faster review turnaround (as would we all), so it will be a priority early in the cycle to identify contributors interested in becoming members of the cinder-core team and mentoring them along so that we can eventually increase the size of the core team during the cycle. In short, things are good, they could be better, and I'd like the opportunity to help drive the project as Victoria PTL. Thank you for your consideration, Brian Rosmaita (rosmaita)

1 0

[neutron] Bug deputy report (Mar 23 - Mar 29)
by Hongbin Lu 29 Mar '20

29 Mar '20

Hi all, I am on the bug deputy last week. Below is the bug deputy report: Critical: https://bugs.launchpad.net/neutron/+bug/1868691 neutron-rally-task fails 100% on stable branches https://bugs.launchpad.net/neutron/+bug/1869034 Postgresql periodic job failing every day High: https://bugs.launchpad.net/neutron/+bug/1868724 KeyError 'gateway_ip' in neutron/services/segments/plugin.py Medium: https://bugs.launchpad.net/neutron/+bug/1869057 extension "subnet_dns_publish_fixed_ips" named wrong in the docs Low: https://bugs.launchpad.net/neutron/+bug/1868515 vpnaas ike policy is not allowed to be updated https://bugs.launchpad.net/neutron/+bug/1868686 ovsdb_timeout config option isn't used to set when adding manager https://bugs.launchpad.net/neutron/+bug/1868933 [fwaas] Update the rules for firewall group without ports will cause the status to change from inactive to active https://bugs.launchpad.net/neutron/+bug/1869121 [FWaaS] Can't add rule with destination_port large than source_port https://bugs.launchpad.net/neutron/+bug/1869342 OVNMechanismDriver _ovn_client is a read-only property Cannot triage (need help from lieutenants): https://bugs.launchpad.net/neutron/+bug/1868697 [ovn] transaction error: {"details":"Transaction causes multiple rows in \"MAC_Binding\" table to have identical values https://bugs.launchpad.net/neutron/+bug/1869129 neutron accepts CIDR in security groups that are invalid in ovn https://bugs.launchpad.net/neutron/+bug/1869244 RowNotFound: Cannot find Bridge with name=tbr-XXXXXXXX-X when using trunk bridges with DPDK vhostusermode https://bugs.launchpad.net/neutron/+bug/1869354 FIP isn't properly created for octavia loadbalancers Invalid: https://bugs.launchpad.net/neutron/+bug/1869136 Use public flat network to create vm faild Best regards, Hongbin

1 0

Re:[qa] Proposing Martin Kopec to Tempest core (Ghanshyam Mann)
by prakash RAMCHANDRAN 28 Mar '20

28 Mar '20

+1 Message: 4 Date: Sat, 28 Mar 2020 20:43:08 -0500 From: Ghanshyam Mann <gmann(a)ghanshyammann.com> To: "openstack-discuss" <openstack-discuss(a)lists.openstack.org> Subject: [qa] Proposing Martin Kopec to Tempest core Message-ID: <17123f4f761.126cbb10d108731.5702022165643836936(a)ghanshyammann.com> Content-Type: text/plain; charset="UTF-8" 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 ------------------------------ Sent from Yahoo Mail on Android

1 0

podman pull failed: Trying to pull Image
by Md. Ziaul Haque 28 Mar '20

28 Mar '20

Hi I have faced a problem with overcloud deploy. If anybody faces the same problem, please suggest to me how I shall solve this problem. My triple version is stein Here I have attached the ansible log [root@controller2 ~]# podman pull 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo Trying to pull 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo...ERRO[0000] Error pulling image ref // 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo: Error initializing source docker:// 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo: pinging docker registry returned: Get https://192.168.90.10:8787/v2/: http: server gave HTTP response to HTTPS client Failed Error: error pulling image " 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo": unable to pull 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo: unable to pull image: Error initializing source docker:// 192.168.90.10:8787/tripleostein/centos-binary-iscsid:current-tripleo: pinging docker registry returned: Get https://192.168.90.10:8787/v2/: http: server gave HTTP response to HTTPS client =========================================================== [root@controller2 ~]# podman info host: BuildahVersion: 1.9.0 Conmon: package: podman-1.4.4-4.el7.centos.x86_64 path: /usr/libexec/podman/conmon version: 'conmon version 0.3.0, commit: unknown' Distribution: distribution: '"centos"' version: "7" MemFree: 11154231296 MemTotal: 16655982592 OCIRuntime: package: runc-1.0.0-65.rc8.el7.centos.x86_64 path: /usr/bin/runc version: 'runc version spec: 1.0.1-dev' SwapFree: 4294963200 SwapTotal: 4294963200 arch: amd64 cpus: 8 hostname: controller2 kernel: 3.10.0-1062.18.1.el7.x86_64 os: linux rootless: false uptime: 17h 37m 6.86s (Approximately 0.71 days) registries: blocked: null insecure: null search: - registry.access.redhat.com - docker.io - registry.fedoraproject.org - quay.io - registry.centos.org store: ConfigFile: /etc/containers/storage.conf ContainerStore: number: 0 GraphDriverName: overlay GraphOptions: null GraphRoot: /var/lib/containers/storage GraphStatus: Backing Filesystem: xfs Native Overlay Diff: "true" Supports d_type: "true" Using metacopy: "false" ImageStore: number: 0 RunRoot: /var/run/containers/storage VolumePath: /var/lib/containers/storage/volumes If I set insecure registry by manual than it pulls the image Thanks Ziaul

1 2

[sdk][osc][ptl][election] OpenStackSDK PTL Nomination
by Monty Taylor 27 Mar '20

27 Mar '20

Hi everybody! I'd like to run for PTL of OpenStackSDK again. We just merged the OpenStackClient and OpenStackSDK teams. While on the one hand this is a nice big new challenge, I think it also presents an excellent opportunity to accelerate our long-standing goal of integrating the two more seamlessly. I'm excited to get some motion on that. In this last cycle we finally got started on the long-awaited python-*client-ectomy from OpenStackClient by removing glanceclient. I'm hoping in the next cycle we can at least remove keystoneclient - but I think we can pick up the pace now. We need to streamline how config and arguments are parsed so that it's 100% consistent between OSC and SDK and Ansible. This is going to mean using openstack.config in OpenStackClient more directly - and I think it's going to mean an end to the double-auth dance. That, in turn, will likely tie in to attempting to unwind the plugin structure from entrypoints and laying in an optimization so that we can skip entrypoints calls in most cases. We've recently been more aggressive with adding new project-specific cores and I'd like to continue that. We need to trust people from project teams to help maintain relevant code in SDK and OSC, and as a result get into the habit of getting support for new things into SDK and OSC as a part of shipping them in the service. That leads to our need to get to the point where both SDK and OpenStackClient can speak to the latest microversion for the projects supporting microversions. This has been mentioned as one of the things people from the projects don't like about OSC vs the project-specific CLIs. The thing is, we will already use the most recent microversion we understand - so we already behave like people want us to. The thing we need to get to is understanding the MV as it's added. The momentum is picking up to get a lot accomplished, and I'd love to keep helping to pushing these rocks uphill. Thanks! Monty

1 0

[openstack-ansible] proposing Erik Berg to openstack-ansible core
by Mohammed Naser 27 Mar '20

27 Mar '20

Hi everyone, I'd like to propose adding Erik Berg to the OSA core team. They've been doing solid contributions with some activity in reviews and I think they'd be an excellent addition to the OSA team If no one opposes, I'll be adding them to the core team in the next few days. Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. https://vexxhost.com

5 5

[tripleo] TripleO CI Summary: Sprint 44
by Rafael Folco 27 Mar '20

27 Mar '20

Greetings, The TripleO CI team has just completed Sprint 44 / Unified Sprint 23 (Mar 05 thru Mar 25). The following is a summary of completed work during this sprint cycle: - Migrated stable branches from rdo-cloud to vexxhost - Upstream TripleO migrated to CentOS-8. - Upstream component pipeline <http://tripleo-cockpit.usersys.redhat.com/d/2tivP9BWz/component-pipeline?or…> done. - RDO content unpinned - First CentOS-8 promotion on March 16th - Promotion server is online and ready for CentOS-8 - Completed development of unified logging with tripleo-quickstart and infrared, roll out in progress Ruck/Rover Notes: - https://hackmd.io/7MBqFHurTA2e5H8kYRwgag The planned work for the next sprint [1] extends the work started in the previous sprint and focuses on the following: - TripleO-Operator-Ansible: contribute w/ code, docs, tests and zuul jobs. - Internal component pipeline: starting work - Unified tempest test skip list The Ruck and Rover for this sprint are Wesley Hayutin (weshay) and Sandeep Yadav (ysandeep). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-24 [2] https://hackmd.io/XMd_vskSTdGZl7ruZ1UckA

1 0

[tc][elections] Nomination
by Donny Davis 27 Mar '20

27 Mar '20

Hello Openstack Humanoids, My name is Donny Davis and I would like to announce my candidacy for TC. I built my first Openstack cloud by hand on the Grizzly release to provide a training environment for fellow employees who lacked Satellite equipment to train on. I have spent subsequent years of my life building, maintaining, operating, and teaching other people how to Openstack. I contribute Openstack CI resources via Fort Nebula (last cycle), and this cycle via Open Edge. This is a cloud that has been tuned specifically for the Openstack Community CI workload. I support many of the obscure requirements to run non-standard CI jobs on this cloud. This Openstack deployment is all my personal equipment and is 100% privately funded. In the last cycle my commit for test instances was mostly 50 concurrent jobs, and this cycle is mostly 40. As a member of the TC, I bring close to a decade of experience as an Operator. I feel the Openstack community can continue to deliver quality code while focusing on easing the burden of getting Openstack clouds into production. For a long time the focus of this community has been to develop bleeding edge features to deliver technical value to consumers. Now this community should focus on making those features easier to consume. I can view the TC through the eyes of a builder, tinkerer, trainer, and long time operator of Openstack. Thank you for your consideration. -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"

1 0

[ironic][ops] Stable Ocata and Pike branches are now Unmaintained
by Iury Gregory 27 Mar '20

27 Mar '20

Greetings Ironicers and Operators, During the ironic upstream meeting held on 09 March 2020, we decided to move stable/ocata and stable/pike to unmaintained [1]. Apologies for sending this email almost 3 weeks after the decision was made. We have documented what unmaintained means in our contributor docs [2]. Feel free to rise any questions here or in the irc channel (#openstack-ironic) [1] http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [2] https://docs.openstack.org/ironic/latest/contributor/#our-policy-for-stable… Best regards, -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

openstack-dev Tacker
by Akshata Jitendra Gage 27 Mar '20

27 Mar '20

Hello, I am new to Tacker. As mentioned in the installation guide i have installed tacker on my server. I need to know that is there any way available by which we can create "service function chaining" via Horizon? And is there any forum related to tacker on which i can raise my doubts and questions? Thanks & Regards Akshata Gage

2 1

[election][neutron] PTL nomination
by Slawek Kaplonski 27 Mar '20

27 Mar '20

Hi, I want to propose my candidacy for Neutron PTL in the Victoria cycle. I have been serving this great team as PTL in the Ussuri cycle already and I would love to continue this in the next cycle as well. Ussuri was my first time as PTL and I learned a lot during this cycle. I think that this new experience and knowledge which I now have will help me serve as PTL in this next cycle as well. In Ussuri I proposed a couple major goals which I wanted to focus on: * merge networking-ovn driver into main Neutron repository - in Ussuri we actually merged networking-ovn code into neutron and made ovn driver as one of the main in-tree drivers for ML2. We also merged the networking-ovn core team into the neutron core team. * Improve overall stability of our CI - we are continuously working to improve CI stability: during this cycle we added couple OVN related jobs to Neutron CI, and we also removed some unnecessary jobs. Unfortunately we didn’t make enough progress with our CI and some jobs still need a lot of work to improve their stability. I think that this is a continuous effort and we will need to focus on it in the next cycle as well. * Improve test coverage for existing features - we introduced many new test cases in the neutron-tempest-plugin repository. Many of them are covering some additional scenarios and advanced functionality: multicast traffic, TCP and UDP port forwarding, and others. I think that this is a continuous effort and we will need to focus on that one in the next cycle as well. * Finish the transition to the new engine facade - this is something which we didn’t make enough progress so far and I would like to treat it as a priority in Victoria. * Improve the stability of Neutron when it is running under uWSGI - recently we promoted our uWSGI jobs to be voting. Those jobs are now pretty stable. I think that in the next cycle we need to finally focus on making uwsgi as the default in Devstack, so that it will be used in most Neutron CI job. In addition to that I wanted to continue Miguel’s way of mentoring potential new core reviewers and contributors, and I think that this has been working pretty fine. In addition to the networking-ovn core team which is now part of neutron core, we also have new core reviewer Lajos Katona and new member of drivers team: Nate Johnston. Our team is now in good shape and we have many active core reviewers and contributors. That’s my summary of what we actually achieved in the Ussuri cycle. Now let’s talk about what are my goals for the Victoria cycle. * Continue adoption of the OVN driver in Neutron - now that the OVN is in-tree, we need to think about making it the default in Devstack. * Finish adoption of new engine facade - it’s unfinished goal from the Ussuri cycle and I think that we should treat it as a priority now, * Metadata over IPv6 - we still have not finished the RFE about support for Metadata service in IPv6 only networks. In the Ussuri cycle we made some progress with the spec [1], and we also had some discussions about it with cloud-init developers. Now I think it’s time to finally get this spec merged and implement it in Neutron, * Continue work on test coverage and CI stability - this is a never ending story and I think that it should be treated with high priority all the time. It is my continuing desire to do my best to help our outstanding team to deliver better software and to grow. [1] https://review.opendev.org/#/c/315604/ — Slawek Kaplonski Senior software engineer Red Hat

1 0

[release] Release countdown for week R-6, March 30 - April 3
by Sean McGinnis 27 Mar '20

27 Mar '20

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on April 2. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/ussuri branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/…) In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (April 9) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, April 9. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/ussuri branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/ussuri branches are cut for a repo, the ability to approve any necessary backports into those branches for ussuri will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: April 2 (R-6 week) Client library freeze: April 9 (R-5 week) Ussuri-3 milestone (including cycle highlights): April 9 (R-5 week) Cycle Highlights Due: April 9 (R-5 week) Ussuri final release: May 13

1 0

[neutron] Final release of non-client libraries
by Slawek Kaplonski 27 Mar '20

27 Mar '20

Hi, Next week is deadline for final releases for non-client libraries and I was checking what patches we are still in review and potentially we would need to have in Ussuri. *Neutron-lib* I see only https://review.opendev.org/#/c/712657/ which potentially may be good to get before final release. IMO it’s in good shape, please review it if You have few minutes (it’s small). *Ovsdbapp* There are 3 opened patches on https://review.opendev.org/#/q/project:openstack/ovsdbapp+branch:master+sta… But I think that maybe only https://review.opendev.org/#/c/683355/ may be potentially needed, mostly by ovn subteam. So please check if this is needed and we should update it to make it in before final Ussuri release. Os-ken I don’t see any important patches waiting in the list https://review.opendev.org/#/q/project:openstack/os-ken+branch:master+statu… so it should be good to go. If I missed anything or You have something else which You need to get in before this final release, please ping me by email or on irc. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][tc] Meeting Agenda April 2nd
by Jean-Philippe Evrard 27 Mar '20

27 Mar '20

Hello everyone, Here are the report topics for the tc next meeting, April 2nd. A few of those are most likely noop, tbh. Feel free to join us! - Report on tc/uc merge (ttx) - Report on the analysis of the 2019 survey (jungleboyj), and survey 2020. - Report on telemetry after Rico's convo with the PTL (ricolin) - report on stable branch policy work: mnaser to push an update to distill what happened on the ML in terms of stable branch policy (mnaser) - report on the community goals for U and V, py2 drop (gmann) - Moving OpenDev discussion forward (clarkb) - Report on the OSF board initiatives (mnaser) Please note that, as usual, the office hours are happening after the meeting, so if you want to chat over new things, it's a perfect place! Regards, Jean-Philippe Evrard

1 0

[tripleo][mistral] Farewell
by Dougal Matthews 27 Mar '20

27 Mar '20

Hey all, I am leaving Red Hat and my last day is tomorrow. As a result I will be moving on from OpenStack. I just wanted to say my farewells here and say thanks to everyone for all the fun over the years. As my last core duty I will be de-coring myself tomorrow :) If anyone wants to reach me beyond tomorrow, my email is probably best: dougal(a)dougalmatthews.com Cheers, Dougal

2 1

[nova][cinder] Why nova-api uses volume's size as bdm.volume_size?
by Zhi CZ Chang 27 Mar '20

27 Mar '20

1 0

[neutron] Drivers meeting - 27.03.2020
by Slawek Kaplonski 26 Mar '20

26 Mar '20

Hi, Due to lack of agenda for our next drivers meeting I will cancel it. I would like You to check list of opened, not triaged, old RFEs [1] and check if there are maybe some RFEs which You would like to continue work on, or maybe there are some which You think we should close as not needed anymore. Also if RFE on this list belongs to You, please respond to any questions from comments in this RFE or just let us know that You don’t want/don’t have time to continue work on it. Thx in advance [1] https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff
by Kendall Nelson 26 Mar '20

26 Mar '20

Hello Everyone! Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Mar 31, 2020 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/victoria/<Project_Name or "TC">/<email_address> (for example, "candidates/victoria/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Apr 07, 2020 23:45 UTC through to Apr 14, 2020 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ATCs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: nomination starts @ Mar 24, 2020 23:45 UTC nomination ends @ Mar 31, 2020 23:45 UTC campaigning starts @ Mar 31, 2020 23:45 UTC campaigning ends @ Apr 07, 2020 23:45 UTC elections start @ Apr 07, 2020 23:45 UTC elections end @ Apr 14, 2020 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2020-03-31 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -Kendall Nelson (diablo_rojo) & the Election Officials

3 2

[oslo] PTL Non-Candidacy
by Ben Nemec 26 Mar '20

26 Mar '20

This won't come as a surprise to most of you, but in case you missed the announcement at the beginning of this cycle I won't be able to serve as Oslo PTL for the next one. While I very much wish this were not the case, I do feel good about the current state of the Oslo team and I'm confident it will continue to do good things under someone else's leadership. Thanks to all of the Oslo contributors who have made the past two years a great experience! -Ben

4 3

[all][ptl] How to Contribute to the OpenStack Blog & Superuser Magazine
by Allison Price 26 Mar '20

26 Mar '20

Hey Stackers— We have received more questions recently about where the community can contribute content, especially on official OpenStack or community channels. Accompanied by the amount of events that have been transformed to virtual experiences, the OpenStack Foundation has been working on ways for the community to centrally share learnings online, and create a place where the community can send project, SIG, and overall community updates. Superuser and the OpenStack blog are community channels—for the community, by the community, so we would really like to get more contributors. We even had a user survey completed yesterday from an operator saying they wish the blog had more information on bug fixes and software updates, so here we are. Here’s how you can contribute: OpenStack Blog <https://www.openstack.org/blog/> We are reviving the OpenStack blog! Here, we want to publish OpenStack bug fixes, software updates, and project milestones that would be beneficial for users to know more about that may be more in depth. Often these are posted on the mailing list, which is great, but could also double as blog posts so that they are searchable in the future when operators stumble upon an issue. Once you have an idea of what you would like to share or have questions, please email community(a)openstack.org <mailto:community@openstack.org>. We can also keep track of a running list of ideas / calls for content for people who have questions that would be great to get answered on the blog. PTLs—heading into the Ussuri cycle, this is a great time to share your ideas on the etherpad around what you can write about. The OpenStack Foundation will reach out to folks who put their names or nicks in the etherpad as well as those who proactively reach out. Superuser <https://superuser.openstack.org/> Superuser has evolved to cover the open infrastructure landscape covering different use cases and open source projects. Whether it’s a video or an article, this content is typically more in depth than what you would see on a project blog and includes things like hands on tutorials, case studies, thought leadership articles, Q&As with open source community leaders, and updates and highlights from open source events around the world. If you have an idea you would like to share, fill out this form <https://superuser.openstack.org/contribute/> and the editorial team will reach out. If you have questions about whether your topic is the right fit, email editor(a)openstack.org <mailto:editor@openstack.org>. You can also attend the OSF community meeting <http://lists.openstack.org/pipermail/foundation/2020-March/002856.html>next week to learn more about how you can get involved and contribute! Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[ironic] The Sanity Preservation Un-Conference, or SPUC - An Ironic gathering!
by Julia Kreger 26 Mar '20

26 Mar '20

Greetings Humans, Vulcans, AIs, and any other form of life! Today in the Ironic team meeting, we decided that we needed to have an un-conference! In the theme of an un-conference, I think we will start with two simple questions: * How is everyone? * What ironic (or non-ironic) things shall we discuss? >From there, we will identify topics of discussion, and possibly jump into separate video calls for ~15 minutes each, depending on the number of topics and general insanity. During the last ?15? minutes or so, we shall reconvene into the same video call to enjoy a little time sipping coffee Coffee, Tea or other delicious beverages while we determine who is wearing the silliest hat! So if you have a steampunk hat with gears or even some kind of hat you would wear to a fancy horse race, go right ahead! Only have a rose from your growing quarantine garden! You can wear that too! So what do you need to do! 1) Fill out the doodle[0] so we can actually schedule a time that works for a group of people! 2) Brainstorm some ideas of things you might want to talk about/present or LEARN! 3) Dust off your silly hats! NB: I know the windows on this doodle overlap with Baremetal SIG doodle that I sent out a little while ago. We will figure it out. -Julia [0]: https://doodle.com/poll/krtn9p4z7xx9pa29

6 8

[nova] API updates week 20-13
by Ghanshyam Mann 26 Mar '20

26 Mar '20

Hello Everyone, Please find the Nova API updates of this week. Please add if I missed any BPs/API related work. API Related BP : ============ COMPLETED: 1. Add image-precache-support spec: - https://blueprints.launchpad.net/nova/+spec/image-precache-support Code Ready for Review: ------------------------------ 1. Nova API policy improvement - Topic: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… - Weekly Progress: Lot of Policies work merged and I am working on remaining ones. - Review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 2. Non-Admin user can filter their instance by availability zone: - Topic: https://review.opendev.org/#/q/topic:bp/non-admin-filter-instance-by-az+(st… - Weekly Progress: Nova change is merged, novaclient change is in-progress - https://review.opendev.org/#/c/713089/ 3. Boot from volume instance rescue - Topic: https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue+(status:op… - Weekly Progress: Code Review is in progress. 4. Add action event fault details -Topic: https://review.opendev.org/#/q/topic:bp/action-event-fault-details+(status:… - Weekly Progress: Few discussion on how we can minimize the info leak to non-admin. discussion is going on. Almost good. 5. Support re-configure deleted_on_termination in server -Topic: https://review.opendev.org/#/q/topic:bp/destroy-instance-with-datavolume+(s… - Weekly Progress: Discussion happened not to use PATCH for this and use existing PUT method. gibi will discuss this in today nova meeting on process and FF wise. Specs are merged and code in-progress: ------------------------------ ------------------ - None Spec Ready for Review or Action from Author: --------------------------------------------------------- -Marking as None here as Ussuri spec deadline is already over. Others: 1. None Bugs: ==== I started fixing policy bugs while working on policy-defaults-refresh BP. 5 bugs have been identified till now and fix up for review. - https://bugs.launchpad.net/nova/+bugs?field.tag=policy-defaults-refresh NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. - https://etherpad.openstack.org/p/nova-bug-triage-ussuri -gmann

1 0

Regarding Split network plane for live migration
by Md. Hejbul Tawhid MUNNA 26 Mar '20

26 Mar '20

Hi, We are using Openstack Rocky . We are observing internal network is using while we do live migration. our internal network interface is 1G. So interface getting full and migration never getting complete. (nova server-migration-list ) 'Remaining Memory Bytes' increasing and decreasing but not getting completed. We have 10G interface for public/external network. I have tried following solution but no luck. still using internal network https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/s… Some Information: [DEFAULT] my_ip = Internal_network_IP [libvirt] live_migration_uri=qemu+ssh://nova@%s.external /system?keyfile=/var/lib/nova/.ssh/id_rsa&no_verify=1 Please let us know if any further information is required. Please advice us if we can solve the issue. Regards, Munna

3 4

[openstack-ansible][elections] Nomination
by Mohammed Naser 26 Mar '20

26 Mar '20

I'd like to announce my candidacy for OpenStack Ansible PTL. As usual, I want to go over all the points I talked about last time and their progress. # Simplifying scenarios for usage and testing We probably haven't progressed much in this, our testing has improved, we did add upgrade testing but unfortuantely that hasn't been as stable. # Using integrated repository for testing and dropping role tests This is pretty much done for the expect of a few corner projects. # Progress on switching all deployments to use Python3 This is also done with some packaging workarounds to make it work with CentOS 7. # Eventual addition of CentOS 8 option We made some progress in this, but it still needs a lot more work, big thanks to jrosser for driving a bunch of this work too. # Reduction in number of config variables (encouraging overrides) This has been done over a few roles now that are using overrides in hopes of minimizing the number of variables to speed up runs. # Increase cooperation with other deployment projects (i.e. TripleO) The Ansible SIG is moving and alive, TripleO uses python_venv_build and os_tempest as well as our connection plugins, so yay. We've worked on getting some new cores as well and making sure the project continues to be sustainable. Thank you for your consideration.

1 0

[tc][elections] Nomination
by Mohammed Naser 26 Mar '20

26 Mar '20

Hi everyone, I want to run again for the OpenStack technical committee for the upcoming cycle. I have been a long time operator of OpenStack with a focus on never using a local for, which has resulted in my involvement with many different projects by making quality-of-life improvements for these services that can help other deployers. I've contributed and worked with different sizes of teams inside OpenStack. >From our big projects such as Nova to projects providing specific services such as Magnum and pretty much most deployments tools at this point. On the operator side, I've helped run one of the longest-running OpenStack public clouds and many private clouds. I've also interacted with many other OpenStack operators that are not as involved in our community, which gives me a significant exposure to our operator story and what that looks like outside our community of known operators. I believe it's time now for me to start driving significant changes in our community to simplify the operator experience, and I think that should start from the technical committee. We're seeing the world evolve around us with new technologies, but we've remained relatively stable and stuck to our "known and trusted" stack. Operators have historically had a lot of frustrations with systems like RabbitMQ and their clustering issues, which end up making the OpenStack experience disappointing. There are many new ways of doing RPC, which we can leverage and help make it even easier to run OpenStack (things such as gRPC). We've also had a history of making it complicated to use containers to deploy OpenStack and historically refused to ship "official" containers. The OpenDev community has built our a step of tooling that can allow us to ship containers very quickly, with nothing more than a well written bindep.txt file and a simple multi-stage build. It's about time that we start having official images and easy ways to deploy OpenStack to reduce those barriers. We define OpenStack as a "cloud operating system." We struggle to deliver much more than the essential infrastructure components. The drive behind OpenStack was to allow people to get more than the necessary infrastructure components. Still, large amounts of different efforts lead us into complicated ways of having to wrangle VMs to run services. With popular container orchestrators and schedulers, OpenStack has a perfect platform to be able to launch those services. By setting up a proper framework, we can start delivering many services such as database as a service, memory store as a service, and so much more by building out Kubernetes operators. It also opens up a whole domain of possible contributors that can use those operators without OpenStack. In closing, I don't expect everyone to agree with all the different ideas I'm putting out. We may only drive just a few of them, or maybe none of them. However, I want to convince you that we need to change. I can understand they sound like big leaps, and they may seem uncomfortable. However, they are genuinely some of the things we need to do to continue to be relevant and put us at the leading edge of technology like we used to be years ago. Thank you for reading this. Regards, Mohammed

1 0

[keystone][horizon] Two approaches to "multi-region" OpenStack deployment
by Krzysztof Klimonda 26 Mar '20

26 Mar '20

Hi, I’ve been spending some time recently thinking about best approach to some sort of multi-region deployment of OpenStack clouds. The two approaches that I’m currently evaluating are shared keystone database (with galera cluster spanning three locations) and shared-nothing approach, where external component is responsible for managing users, projects etc. Shared keystone database seems fairly straightforward from OS point of view (I’m ignoring galera replication over WAN woes for the purpose of this discussion) until I hit 3 regions. Additional regions must either reuse “global” keystone adding latency everywhere, or we need a way to replicate data from “master” galera cluster to “slave” clusters, and route all database write statements back to the master galera cluster, while reading from local asynchronous replica. This has me worried somewhat, as doing that that into eventually-consistent deployment of sort. Services deployed in regions with asynchronous replication can no longer depend on the fact that once transaction is finished, consecutive reads will return up-to-date state. I can imagine scenarios where, as an example, trust is setup for heat, but that fact is not replicated back to the database by the time heat tries to issue a token based on that trust and the process fails. The other approach would be to keep keystone databases completely separate, and have something external to openstack manage all those resources. While not sharing keystone database between regions sidesteps the issue of scalability, and the entire setup seems to be more resilient to failures, it’s not without its own drawbacks: * In this setup Horizon can no longer switch between regions without additional work (see notes below) * There is no longer single API entrypoint to the cloud * Some Keystone API operations would have to be removed from users via custom policy - for example, managing user assignment to projects (for users who have domain admin role) Additional thoughts Could horizon be modified to switch endpoints based on the region selected in the UI? Is the token reissued when region is changed in horizon, or is single token used? I’m assuming it’s the former given my understanding that when projects are changed, a new token is issued - but perhaps the initial token is always used to issue project-scoped tokens for Horizon? In the second scenario, with separate keystone databases, a backend for keystone could be created that proxies some operations (like aforementioned user assignment) back to the external manager so that it can be propagated to other clouds. Does that even make sense? In the end I’m reaching out in hope that someone could chime in based on their experience - perhaps I’m missing a better approach, or making wrong assumptions in my email, especially around asynchronous replication of keystone database and its effect on services in regions that may not have up-to-data view of the databas. Or perhaps trying ot synchronize keystone state by external tool is not really worth the additional effort that would require. -Chris

6 8

[tripleo] ptg topics
by Wesley Hayutin 25 Mar '20

25 Mar '20

Greetings, It's that time of year to start collecting topics for the PTG [1]. The in person PTG has been switched to a virtual meeting [2]. So the bad news is that the world is upside down atm, but the good news is that you may have a better lunch at the sessions ( I kid.. ) You can help plan the virtual ptg by signing up @ https://etherpad.openstack.org/p/Virtual_PTG_Planning Thanks all!! [1] https://etherpad.openstack.org/p/tripleo-victoria-topics [2] http://lists.openstack.org/pipermail/foundation/2020-March/002854.html

1 0

[all] Collecting Virtual Midcycle Best Practices
by Kendall Nelson 25 Mar '20

25 Mar '20

Hello Everyone! I wanted to collect best practices and pitfalls to avoid wrt projects experiences with virtual midcycles. I know of a few projects that have done them in the past and with how travel is hard for a lot of people right now, I expect more projects to have midcycles. I think it would be helpful to have all of the data we can collect in one place for those not just new to virtual midcycles but the whole community. I threw some categories into this etherpad[1] and filled in some options. Please add to it :) -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/virtual-midcycle-best-practices

4 8

[tripleo] rdo registry migration
by Wesley Hayutin 25 Mar '20

25 Mar '20

Greetings, FYI.. the rdo registry is migrating from RDO to Vexxhost. You may find some of your jobs hitting "retry_limit" [1] This was caused by a default to log into registries for jobs running in rdo. The default has been updated. Jobs should return to their "GREENISH" status shortly [1] https://review.rdoproject.org/zuul/builds?job_name=tripleo-ci-centos-8-ovb-…

1 0

[heat][magnum][tripleo] Official build and test plan for heat container agent
by Rico Lin 25 Mar '20

25 Mar '20

Dear all tl;dr: Shall we build, publish, and test heat container agents on heat-agents directly?:) Please help to review https://review.opendev.org/#/q/topic:build-container-agent+(status:open) Current I think we encounter with following issues: ** No functional/scenario test for heat-agents but only unit tests* Right now, whatever patch people send up in heat-agents, we only vote against unit tests. This makes no sense for long term maintenance. Which makes me thinking of the second issue. ** No enable scenario tests for software deployment:* We have tests defined, but since we didn't build any customized image. We didn't enable it for a long time. To build a container image for heat-agents (aka heat container agent) is (IMO) the best way for us to enable these teats. Which we can also use it to cross gating on heat and heat-agents (or even heat-template). The no much to change for the test itself but only update the config script to enable the container. ** Can't guarantee cross-project usage:* We currently provide no guarantee for any usage of heat agents from other projects, especially Magnum and TripleO (I didn't personally check if TripleO still using it, but since they still have experiment CI running) who uses heat container agents. It will be nice if we provide basic images for other teams can build their additional requirements. To resolve the above issues, I propose [1]. Which a lot of logic was copied from the current magnum heat container agent scripts [2] so we can start with a higher possibility to allow magnum to reuse our works. For a more detail approach in [1]. The patch defines a build job in `check` pipeline. And a publish job in `post-check`. Uses zuul secrets to save docker authN information. As for the account, I created a new `openstackheat` account [3] for it (I specifically recall there ware discussion about having an official image hub for OpenStack, but not quite sure what happened since). The current approach also can support multiple architectures (like amd64 arm arm64 ppc64le s390x, etc). But for now, I think we should have tested before we publish for other architectures. You can run the build or publish job easily by running `make build-images-all-archs` to build images for all architectures or `make upload-images-all-archs` to build and publish images for all architectures. [1] https://review.opendev.org/#/q/topic:build-container-agent+(status:open) [2] https://opendev.org/openstack/magnum/src/branch/master/dockerfiles/heat-con… [3] https://hub.docker.com/r/openstackheat -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 1

[cinder][qa] propose Liang Fang for devstack-plugin-open-cas-core
by Brian Rosmaita 25 Mar '20

25 Mar '20

Liang Fang is driving the effort to create the devstack-plugin-open-cas and use it to test the cinder/nova volume-local-cache feature with tempest. Since he's our SME on open-cas, I propose that he be made a member of devstack-plugin-open-cas-core. (Currently, the only members of that group are the members of cinder-core and devstack-core.) In the absence of objections, I'll make the change before the next Cinder team meeting (Wednesday, 25 March at 1400 UTC in its new location of #openstack-meeting-alt). cheers, brian

4 4