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

[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