- openstack-discuss - lists.openstack.org

[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