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

[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