Closed aepfli closed 1 year ago
This seems like a nice improvement that will help make the org permissions more transparent and easier to understand.
i do have somewhat issues to split permissions between approvers, and triagers - as the permissions seems to be the same for me, the question is, if it is worth to differentiate between both of them, and if we should reflect this also in the structure of the groups
Is this the project https://github.com/uwu-tools/peribolos ?
I also want to add some clarification here:
What do we want? ~We want to have a GitOps way of assigning different permissions to members of our organization.~ We want to have a straightforward approach with little to no duplication or too many points to edit alignment We want to organize our members in teams with certain aspects. We don't want to assign permissions per individual but on a team basis, so if you want specific permissions, you're part of a certain team. We want to group repositories for teams, aka one team is responsible for multiple repositories - to reduce maintenance efforts We also want to have overlapping teams for repositories, as there might be the need to separate some access
The process and technology isn't important, the outcomes are.
I am happy to bring this up at the next governance meeting though as I think it's great you're bringing this up!
actually it is https://docs.prow.k8s.io/docs/components/cli-tools/peribolos/ - we extracted it into our own docker image, to be easier used with github actions
Seems to be close to the same idea as uwutools :)
-We want to have a GitOps way of assigning different permissions to members of our organization.
+We want to have an easy and trackable way of assigning different permissions to members of our organization.
@AlexsJones I totally agree, i hope this change of wording helps in regards of the goals :)
Proposal
Community, Membership, and Repository management is complex on its own. With a growing community, keeping an overview gets harder and harder. Instead of relying on manual actions, I recommend switching to a GitOps approach, utilizing Peribolos.
Peribolos offers a great variety of settings and can be used to manage organization management, team assignments, and repository permissions.
Peribolos is developed and used by Kubernetes and is a good fit for OpenFeature.
What do we want?
Permission structure
Organization Level
First, we do have roles on organizational level like:
With respective permissions
Repository Level
Additionally, if you are part of the organizational level, you can also be one of those roles just for the repository or repository group:
Proposal
Ultimately, we can setup the repo permissions for each repository, which means a lot of duplicated configuration effort, but grouping would be easier and way better to handle. Furthermore, it would represent the community structure in a better manner.
Theoretically, we could group the repository as follow (naive proposal)
* sdk * java - https://github.com/open-feature/java-sdk - https://github.com/open-feature/java-sdk-contrib * javascript - https://github.com/open-feature/js-sdk-contrib - https://github.com/open-feature/js-sdk * .net - https://github.com/open-feature/dotnet-sdk - https://github.com/open-feature/dotnet-sdk-contrib * go - https://github.com/open-feature/go-sdk-contrib - https://github.com/open-feature/go-sdk * php - https://github.com/open-feature/php-sdk - https://github.com/open-feature/php-sdk-contrib * ruby - https://github.com/open-feature/ruby-sdk - https://github.com/open-feature/ruby-sdk-contrib * python - https://github.com/open-feature/python-sdk - https://github.com/open-feature/python-sdk-contrib * rust - https://github.com/open-feature/rust-sdk * education - https://github.com/open-feature/docs.openfeature.dev - https://github.com/open-feature/killercoda - https://github.com/open-feature/playground * org - https://github.com/open-feature/ofep - https://github.com/open-feature/community - https://github.com/open-feature/.github - https://github.com/open-feature/spec * utils - https://github.com/open-feature/test-harness * cloud native - https://github.com/open-feature/flagd - https://github.com/open-feature/watchman - https://github.com/open-feature/schemas - https://github.com/open-feature/open-feature-operatorAs the configuration file for this structure would be already quite big and cover a lot of duplication
I propose consolidating this into a leaner structure with an automatic merge (like Kubernetes is doing https://github.com/kubernetes/org) tailored to our needs. We will have our Directory per organization we manage and a subdirectory per group containing the necessary information.
The
org.yaml
will contain basic information about the organization, such as general membership, description, etc. Also it will contain a group for Community maintainersThe group configuration will contain the following structure, eg. for java
Our merger will then take all this information to generate the configuration and apply it via GitHub Action to the defined organizations.
References