OpenStack PTG for Xena development planning and discussions are held virtually from 19 – 23, April 2021. Overall we had good discussions and another successful virtual PTG though most of us missed the face-to-face interaction. This blog covers the OpenStack Technical Committee discussion that happened on Tuesday and Friday.
Pop Up Team Check-In
Currently, we have two pop-up teams 1. policy-popup 2. Encryption, as per checks, both are active, and
we will continue on both teams in the Xena cycle. policy pop-up team almost served its purpose and ready to
be converted as community-wide goal as next step which can happen in Y cycle.
Community-wide goals Check-In
*In the Wallaby cycle, we selected two community-wide goals. In PTG we checked the progress and any blocker.
1. Migrate RBAC Policy Format from JSON to YAML
This is almost completed, only heat and few patches in openstack-ansible are pending. Tracking etherpad.
Action Items: Finish the pending patches to merge.
2. Migrate from oslo.rootwrap to oslo.privsep
ralonsoh could not join this session due to conflict with neutron sessions, but this needs more work and will
continue in Xena cycle too.
Action Items: Continue this work in Xena cycle
* Along with the above goals, we checked a few previous cycle goals pending work also, and the below two are pretty
simple and important to complete. We will spend some time finishing these in Xena cycle.
1. offline pdf doc: https://storyboard.openstack.org/#!/story/list?tags=pdf-doc-enabled
2. Contributor guide: https://storyboard.openstack.org/#!/story/2007236
Assignee: gmann, diablo_rojo
*Y cycle goal selection.
As per the community-wide goal schedule, we need to start the goal selection for the Y cycle. We have two
TC members volunteer to drive this work.
Assignee: ricolin, diablo_rojo
TC tag advertising and encourage project adoption.
We discussed the TC tags adoption and if it is worth continuing it or who actually gets benefit from these. It
is not so clear if they are being checked by users or anyone. Projects are adopted in production by their stability
and feature, not just by tag. We decided to review each tag for its usefulness and cleanup. Based on what left,
we can make a decision on whether to continue the tag concept or not.
Action Items: Review each tag for its usefulness and cleanup
Assignee: yoctozepto, jungleboyj
Discussion on moving OpenStack to a yearly release cycle
This topic has been discussed before also and it was live-streamed on youtube too, which you can watch.
Discussion is about if the current 6-month release cycle is fine/fast for consumers to adopt the releases/upgrade etc. There were both
side arguments about moving OpenStack release to 1-year cycle and it was not so clear if that actually solve the
upgrade/consuming feature or not. Also, there are few points on developer perspective and being a long 1-year release
can slow down the community activeness and developer time for upstream work. But there were more important
points also which I did not summarize here but you to watch the youtube video for details.
In summary, there is no consensus on this and we gathered some of the action items to continue this get feedback or
educating about upgrade operation guides& best practices.
* Reach out to the Project team + operators about feedback via ML.
* Encourage “Operation Docs and Tooling” SIG to add upgrades and operational education guideline
Assignee: I forgot to ask the volunteer for this, please let me know if anyone would like to help with this.
Below is what we discussed in the previous cycle retrospective
* TC is more productive with the weekly meetings which helped to speed up the review and discussions.
* Happy to see TC engagement on the gate and infra stuff. We will be continuing this as our weekly meeting agenda too. Thanks
to dansmith to initiate this
* Did not promote election well. We discussed this in detail as a separate topic, I am writing the summary for this in the below section.
* We need more interaction with project/SIG(and also popups?:) ) team. Ditto, I am writing the summary for this in the below section.
* Doing great with settling projects to DPL and also we have zero projects left behind as leaderless.
* Landed the TC stance on SDK/OSC Patch
* Started SIG audit too in terms of health checks which is good to keep SIG list active and maintained Thanks to ricolin and diablo_rojo.
* Thanks to mnaser and diablo_rojo for serving as Chair/Vice-chair and running the show in a great way.
Getting projects to broadcast out/mentor
This topic is about encouraging projects to broadcast out successes, wins, and possibly get people in projects to engage in some public
speaking of their work, why it is important to them, the change they see it making in the world, team values, what does the team find important.
We discussed the various way to achieve that and some of part is about marketing the things. There is openinfra live tv which broadcast the
live sessions every Thursday, take more help from the foundation or reach out to local user groups. Apart from marketing stuff, TC will
definitely encourage projects to start talking about the more and more technical stuff in public speaking.
* TC to reachout to board/foundation to provide an exact platform for broadcast these, existing or any new platform
* TC to document this as best practice to do by projects in project team guide.
Assignee: spotz, belmoreira
How do we not break cross-vendor drivers?
This discussion was about cross-vendor drivers. In Ironic, w recent change to redfish drivers was found to break in one
case on another vendor. Even current stable policy state in appropriate-fixes section on taking the best decision on backport
fixes. Projects can take decisions as per the project and user’s best interest which will help everyone. We talked about the
stable policy process in the next topic which is going to help projects in such cases.
Stable core team process
We have talked about this in shanghai PTG also but did not proceed with any resolution. We are facing a few issues with the
stable backport merges. The stable maintenance team is not so active as it used to be. There is a delay in adding more core
in stable project groups or merging the backports. Elod mentioned that right now that generally when people have questions,
they refer them to the policy documents and make a decision.
We definitely want to fix the current issues and the good news is that we agreed to do few changes on stable policy like let the project
core team manages the project side stable team and also policy they would like to define as per the project’s use case.
* Add a resolution and modify stable policy doc for the below changes:
** Let the project team manage the project’s stable core team, Global stable maintenance core team is continuing on general advice and help.
** Projects are allowed to define any addition or own policy on top of general stable policy guidelines.
Assignee: jungleboyj, mnaser/gmann (gmann to check if mnaser is ok with this item)
Stable EM to EOL transition
There are 9 stable branches currently (will be 8 soon after ocata moves to EOL) including EM or maintained stable. Discussion is about the
maintenance effort for these many stable branches. how we can handle the supporting team load for EM branches like QA, infra etc. Many projects
gate on EM stable branches is broken. QA team or elod end up spending lot of time during py2 drop time on EM branch even we still fix those.
But in future, we might not have that much volume on EM branch maintenance. With that, we did not conclude on reducing the number of EM
branch and continue as it is.
But as ‘unmaintained phase is not so clear and not real phase branch transition to, we agreed to remove this phase and let EM branch directly move to
EOL state based on their current lifecycle or maintenance.
Action Items: Remove the “Unmaintained” phase
Next, we talked about the TC process & workflow things.
Meeting time check
As we have two new TC members, we checked on the current meeting time. The current time Thursday 15 UTC is
ok for all TC members and we will continue that.
Office Hour continuation
TC office hours are still inactive and we discussed if we want to continue on these or we can remove especially when
we have weekly meetings. The consensus on this is to continue with the one office hour which is in Asia TZ.
Action Items: Keep one office hour
Charter revision for election vacant seat
This was the first time in the TC election that we had one vacant seat. There was discussion on reducing the
TC seats (this requires the charter change but we did not have full TC members to do the charter change) or
doing a special election which we went with a special election. This is something we tool as an action item to
make our charter handle this situation in future if occur.
We also talked about how we can engage AUC in election or voting and decided to add a way for them to be
* Charter change to write the process to handle these vacant seat situations and how to make a charter change in absence of complete TC or so.
* Document the process for adding SIG+project contributors, AUC as extra ATC.
How we can improve our election promotion
In past couple of elections, we have noticed that many members miss the nomination deadline also fewer members step up
for the leadership role. We discussed few ways to improve the election promotion but there is no concrete things we agreed on
Another but important thing we discussed is how to add more members to the election official team. Every time it’s fungi or diablo_rojo
helping in front. We decided that we will have two TC members volunteer for every cycle election official or encourage community
members to be part of this wG.
Action Items: Make a process to ask two TC volunteers for an election official in addition to existing election officials.
Assignee: spotz, diablo_rojo
Project Health checks
We tried a few ways in past to improve the interaction between TC and the project side. TC liaison is our current way to
check project health and interaction but that is not so active or helpful. Rico suggested trying some automatic way to
check the contribution stats. But apart from that we did not decide any conclusion on that and will continue this discussion
in the TC meeting.
* automate the process to check the health in term of contribution/review/release/gate
* Continue this topic in the weekly meetings.
Assignee: belmoreira, ricolin
Mechanism to define the TC track-able targets per cycle (or redefine the TC tracker)
This is to try a mechanism for TC working items per cycle. We agreed to track these in etherpad and check
status in our weekly meeting.
Action Items: Create the etherpad for Xena cycle tracker: https://etherpad.opendev.org/p/tc-xena-tracker
Feel free to ping me in case you have any questions.