In vPTG (bobcat), we discussed about removal of old deprecated rules
and we should have at least one SLURP release between we enable the
new defaults by default and remove the old rules. For example, if
new rules are enabled in B(non SLURP) then removal should not be done
in C (SLURP) so that SLURP upgrade can notice the new rules enable
for at least one SLURP release.
- https://etherpad.opendev.org/p/rbac-2023.2-ptg#L36
Change-Id: I2cc408c4c7b8b147217b2f11697d36e58017db91
Goal implementation should be finished during 2023.1 development cycle.
In order to start progressing on it we should select goal for
implementation first.
Change-Id: Ib3893bc1fafd8626465de4f9d9ff467404bea97c
Ubuntu 22.04 has been released on April 21 and by now already have first
point release as well as upgrade path from 20.04 (Focal). By the end of
Antelope development cycle Ubuntu 22.04 will be around for a year,
which makes a good timing for us to set a goal of migrating CI/CD jobs
to start using this distro.
Change-Id: Ic89ae25dcaebc4f27e9214a857d4d681d0992667
In Zed cycle, we started collecting the operators feedback
- https://etherpad.opendev.org/p/BER-2022-OPS-SRBAC
- https://etherpad.opendev.org/p/rbac-operator-feedback
and based on that we changed the direction for RBAC goal:
1. Finish delivering project personas. This is to introduce the member
and reader roles to operate things within their project. By default,
any other project role like foo will not be allowed to do anything
in the project.
2. Change in scope implementation. Services with project resources
(except Ironic as they have user using the system scope) that have
already implemented scope (or have yet to) should make all policy
rules set scope_types=['project'].
Discussion reference for policy popup team
- https://etherpad.opendev.org/p/rbac-zed-ptg#L171
Change-Id: If7b052149df3f37f2173e6719c8c6d0d81787cc7
As discussed in Yoga PTG TC+PTL interaction sessions[1],
adding goal checklist to know if goal is ready or not.
Also, remove the goal schedule which was needed when goal
were coupled with development cycle.
[1] https://etherpad.opendev.org/p/tc-ptl-interaction
Change-Id: I91c21233673c75f37461094dcf1fbb9ef4ca2e5e
Community-wide goals are not coupled with cycle so
this commit adds a clarity on slected goals are Active goals
even they are targetted for more than one cycle.
Change-Id: I900a3912dd2e78fa5b267512e0f817db8bda1ec2
As per the new structure of community-wide goal[1],
we will keep all the completed goals into separate
directory 'goals/completed/' which will help to
track the goals and a clear view on what all goals
still need more work.
Keeping 'Migrate from oslo.rootwrap to oslo.privsep'
goal in the selected directory only as this still need to
finish the work. Rest all previous cycle goals are moved
to 'goals/completed/' directory
[1] https://governance.openstack.org/tc/goals/#completing-goals
Change-Id: I6c0d979038f65abb091db646ddb4c0d09c43735a
RBAC goal has been reworked and has clear direction now.
As per the new structure of community-wide goals, goal
will not be associated with any cycle release but will have
different milestones. This goal has defined the different
milestones to complete the work.
Change-Id: I52744507cf5be6e47e96c69af4300cb84018c2e9
The Yoga PTG shed a lot of discussion on the useage of system scope and
default roles.
The yoga community goal is still useful, but the discussions highlighted
some confusion in the current approach. We should update the goal to be
consistent with the discussions from the yoga PTG.
This goal is divided into phases spanning the next few development
cycles.
Co-Authored-By: Ghanshyam Mann <gmann@ghanshyammann.com>
Change-Id: I061994e17bd96ace9e3d2040d342b71d3add99cc
As discussed in Yoga PTG[1], we are decoupling the
community-wide goals from release cycle which will
give us benefit to:
- have a set of goals always active for community to work
whenever we get help or bandwidth.
- Divide the goal into different milestones
- Complete the goal as per set targets instead of fogetting
it once cycle is completed.
[1] https://etherpad.opendev.org/p/tc-yoga-ptg
Change-Id: I6a3120193147cd0d46c04106283fa7d5519f9cb0
As discussed in Yoga PTG, we need to rework the implementation
for the new secure RBAC.
- https://etherpad.opendev.org/p/tc-yoga-ptg
We will continue to rework the implementation in
goals/proposed folder and once it is ready then we will select this
as goal.
Change-Id: I1ce58b1c42ce1e24116a54b6fc136bf6bbcdc818
It was already mentioned that: "There is no minimum or maximum limit
on the number of goals to be selected per cycle".
With this change we explicitly mention that the TC can decided that
a release cycle can have no community goals.
Change-Id: I47ff25f7b1b7b712628f0c6ca03886a7de929a0c
The default sort is alphabetical, causing the most recent goals to be
further and further down the list of selected goals. This reverses the
sort order so that the most recent and relevant series goals are at the
top of the list.
Change-Id: Ifd0cb584d71e7d08acc5c5960707d2bd954f48ae
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Update a few links:
- to the restored Zuul v3 migration guide;
- to the Zuul jobs reference;
Update the information about the grenade jobs and add
a few examples.
Change-Id: I85090964cbccb0796552f61556dfaa9591a6d459
We discussed this in Victoria PTG to clarify the goal
count which is not always two goals per cycle
- https://etherpad.opendev.org/p/tc-victoria-ptg
Change-Id: I9f471207e8af750e579b475874b247662604cbbb
There are few QA projects keeping py3.5 support,
let's document them also in list to know complete list of projetcs
keeping py3.5 support.
Change-Id: I410b9e2072460c568a15546c4605fab154299104
Some bullet items were over-indented, causing bullet items to also be
block quoted.
Change-Id: Ic4cbf0518216521bbbebd9d439e39289705cf625
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Stephen Finucane