As I sit down to describe the highlights of the virtual OpenDev PTG of June 2020, the first thing I have to say is that the virtual participation is a two edged sword. On one hand, the spontaneity of the hallway track and the ability to quickly drop in to another group's meeting were largely lost. But I think that there were some people in the Neutron room that would not have been able to make it if the event was held in Vancouver. Once the pandemic is in the rear view mirror, I hope that we can resume in-person events. But I think that there is potential value to interspersing virtual events with the in-person variety, to reach out to students, small companies, and ravel-averse companies or individuals. I'd also like to say that the Foundation staff did a great job with running an event that so completely broke from precedent. The choice of two videoconferencing platforms, with the ability of teams to select the one that matched their needs the best, was foresighted since certain areas had access issues with certain platforms. --- Technical Committee --- I felt that the TC sessions at this PTG were very productive and valuable. In particular, we used the 'raise hands' feature in Zoom to ensure an orderly exchange of views that gave everyone a chance to speak, and I felt that went very well. A few of the highlights of what the TC discussed and decided are: 1.) The TC decided to draft a policy change to provide a model for a project without a PTL. If an interested project was interested in changing to a PTL-less model they could opt-in to such a model, but for projects that do not opt in nothing would change. When imagining how a project could function without a PTL, we deconstructed the role into it's component parts, including: interfacing with the release, infrastructure, and security teams; doing the necessary prep work for PTG and summit events; acting as a public contact point for the project; acting as the bug resolver of last resort. Of these the only ones that are essential from a TC perspective are the release liaison and the infrastructure liaison (for CI issues); the VMT team already has a list of subject matter experts they consult for vulnerabilities. An events person may be called for on a per-event basis - and if no one steps forward for a project, then that project wouldn't be represented at that event. There's definitely more responsibility diffused within the project team in this model, without a "the buck stops here" PTL position. And not every question is answered - for example, who looks for potential cores to mentor and bring up to speed while still ensuring diversity in the core group over time? Look forward to a governance proposal in the coming month or so about this topic, and hopefully a lively discussion that will help us sort out the rough edges! 2.) There has been an increasing consensus that the division between the Technical Committee and the User Committee of OpenStack is an artificial one, a relic of the rapid-expansion phase of the OpenStack universe and not in keeping with the current OpenStack environment. In particular, with more operators contributing back and interested in guiding the technical evolution of OpenStack, the dichotomy between developers and operators/users seems false and sends the wrong message. To that end, the TC has formally proposed that the TC and UC should merge into a single body. Because changes to the Foundation bylaws are costly and slow, we would like to execute this merger without changes to the foundation bylaws. Since the TC is specified in greater detail than the UC in the bylaws, the merger would be accomplished by the UC becoming a subset of the TC. This change was anticipated by the higher rate of operators being nominated and elected to the TC this past election, and the proposed governance change [1] completes a merger that has been a long time in coming. 3.) There has been some feedback from operators that the unfinished migration from project-specific clients to the unified OpenStack client causes uncertainty and difficulty for both operators and users. Some have even created their own client that hides the difference between the unified client and the remaining project-specific clients. This is obviously a bad experience and something we can improve. Given this, the TC will place a greater emphasis on preparing the community to conclude the migration to OSC. 4.) The community goals for the V cycle have been selected, and they are to conclude the migration to Zuul v3, and to migrate the base Ubuntu image used in the upstream gates from Bionic 18.04 to Focal 20.04 [2]. 5.) In the U cycle the TC created the 'ideas' repository [3], which is a place for people to post ideas that they think would be great for the OpenStack community. We did this after reflecting that there are a lot of great ideas that are discussed on the mailing list that are perhaps a bit ahead of their time, and then get lost in the mailing list archives. Rather than forgetting about an idea, it could be posted to the ideas repo and then brought back when time is right. Rather than shifting the graveyard for ideas from the mailing list to this repo, the TC or a representative could review the tabulated ideas with an eye to what is ready for revival and discussion in a PTG or forum session. --- Neutron --- The Neutron community made good use of the Jitsi/Meetpad platform after a few opening hiccups. It handled the large number of people in the room well for the most part, and the etherpad integration was interesting. I think it was great how the Neutron team worked well with the Keystone, Nova, Cyborg, and Edge SIG teams and had great collaboration on each front. The themes in the Neutron community were the same as they have been before: stadium projects are increasingly being run by the Neutron core team, those that are not are entering hibernation, with networking-midonet currently at the most risk. The community slowly pushes forward with Engine Facade and is looking to fully deprecate python-neutronclient. We acknowledged that the neutron-lib migration has stalled and decided to make the process easier with debtcollector deprecations. The biggest thing for me in the summit was the decision to move forward with ML2/OVN as the default back end for Neutron, including in devstack. This will be proposed to the broader community and the Neutron team will work with everyone to make sure this is a success. In conclusion, I am as always grateful for the tremendous worldwide OpenStack community. I am proud of how much was accomplished, and I think this PTG sets the stage for a great Victoria cycle. Thanks, Nate [1] https://review.opendev.org/#/c/734074/ [2] Waiting on https://review.opendev.org/#/c/731213/ to be merged [3] https://governance.openstack.org/ideas/