I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
* Source Git group (https://gitlab.com/fedora/src) -- not what you think it only has 4 repos so far * Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go under marketing maybe * Packager-Tools (https://gitlab.com/fedora/packager-tools) * people (https://gitlab.com/fedora/people) a private group with one repo in it
This might have to be something that we have a meeting to discuss and figure out a scheme?
cheers, ryanlerch
On 04/08/2023 02:25, Ryan Lerch wrote:
I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
- Source Git group (https://gitlab.com/fedora/src) -- not what you
think it only has 4 repos so far
- Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go
under marketing maybe
- Packager-Tools (https://gitlab.com/fedora/packager-tools)
- people (https://gitlab.com/fedora/people) a private group with one repo in it
This might have to be something that we have a meeting to discuss and figure out a scheme?
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin fabian.arrotin@arrfab.net wrote:
On 04/08/2023 02:25, Ryan Lerch wrote:
I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
- Source Git group (https://gitlab.com/fedora/src) -- not what you
think it only has 4 repos so far
- Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go
under marketing maybe
- Packager-Tools (https://gitlab.com/fedora/packager-tools)
- people (https://gitlab.com/fedora/people) a private group with one repo in it
This might have to be something that we have a meeting to discuss and figure out a scheme?
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
Oh, i can also definitely get on board with a set scheme for Fedora Accounts groups <-> Gitlab Groups naming conventions.
However, the one of the main issues i am noticing with our current GitLab setup is that the groups that are being added are being done in an adhoc setting.
For example, there are groups for Council and Mindshare (and not yet, but i can imagine a FesCO group too) -- should these be grouped together under, say a "Governance" Sub group?
cheers, ryanlerch
-- Fabian Arrotin gpg key: 17F3B7A1
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 04/08/2023 08:49, Ryan Lerch wrote:
On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin fabian.arrotin@arrfab.net wrote:
On 04/08/2023 02:25, Ryan Lerch wrote:
I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
- Source Git group (https://gitlab.com/fedora/src) -- not what you
think it only has 4 repos so far
- Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go
under marketing maybe
- Packager-Tools (https://gitlab.com/fedora/packager-tools)
- people (https://gitlab.com/fedora/people) a private group with one repo in it
This might have to be something that we have a meeting to discuss and figure out a scheme?
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
Oh, i can also definitely get on board with a set scheme for Fedora Accounts groups <-> Gitlab Groups naming conventions.
However, the one of the main issues i am noticing with our current GitLab setup is that the groups that are being added are being done in an adhoc setting.
For example, there are groups for Council and Mindshare (and not yet, but i can imagine a FesCO group too) -- should these be grouped together under, say a "Governance" Sub group?
cheers, ryanlerch
Multiple solutions : one can always create new groups and reflect that at gitlab level (same membership but different group name[s]) and IPA supports multiple "nesting" levels so you can (in your Governance example) have one groups containining/nesting multiple other ones
How the FAS and Gitlab groups are synced? Do we need to have them named same?
Michal
On 04. 08. 23 14:04, Fabian Arrotin wrote:
On 04/08/2023 08:49, Ryan Lerch wrote:
On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin fabian.arrotin@arrfab.net wrote:
On 04/08/2023 02:25, Ryan Lerch wrote:
I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
- Source Git group (https://gitlab.com/fedora/src) -- not what you
think it only has 4 repos so far
- Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go
under marketing maybe
- Packager-Tools (https://gitlab.com/fedora/packager-tools)
- people (https://gitlab.com/fedora/people) a private group with
one repo in it
This might have to be something that we have a meeting to discuss and figure out a scheme?
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
Oh, i can also definitely get on board with a set scheme for Fedora Accounts groups <-> Gitlab Groups naming conventions.
However, the one of the main issues i am noticing with our current GitLab setup is that the groups that are being added are being done in an adhoc setting.
For example, there are groups for Council and Mindshare (and not yet, but i can imagine a FesCO group too) -- should these be grouped together under, say a "Governance" Sub group?
cheers, ryanlerch
Multiple solutions : one can always create new groups and reflect that at gitlab level (same membership but different group name[s]) and IPA supports multiple "nesting" levels so you can (in your Governance example) have one groups containining/nesting multiple other ones
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Aug 07, 2023 at 01:43:09PM +0200, Michal Konecny wrote:
How the FAS and Gitlab groups are synced? Do we need to have them named same?
It's via SAML2 and the groups _can_ be named anything, but we should really use a convention.
Basically on the gitlab side you tell it: this saml2 group = this permission on gitlab
kevin
On Fri, Aug 04, 2023 at 02:04:22PM +0200, Fabian Arrotin wrote:
On 04/08/2023 08:49, Ryan Lerch wrote:
On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin fabian.arrotin@arrfab.net wrote:
On 04/08/2023 02:25, Ryan Lerch wrote:
I just would get a discussion started with the process of semi-formalizing the grouping and naming guidelines for the Fedora GitLab instance.
Just a nitpick, this isn't a Fedora Gitlab instance. ;) it's a namespace on gitlab.com provided to us from gitlab.
Currently there are a bunch of groups with subgroups in the main /fedora/ namespace:
Depending on how we decide to group, some of these may remain there (or possibly be grouped together in another group) This is however some repos and groups that i'm not sure what they are or could probably be moved into some existing groups:
- Source Git group (https://gitlab.com/fedora/src) -- not what you
think it only has 4 repos so far
This was the 'source git sig' wanting to try things out on gitlab. It could be moved to SIGs I think? We might ping them and see if it's even still needed however, since I don't know that they are active much these days. ;(
- Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go
under marketing maybe
Sounds reasonable.
- Packager-Tools (https://gitlab.com/fedora/packager-tools)
Yeah, not sure about this one... I mean it's the mass prebuild tool, but not sure where moving it would make sense.
- people (https://gitlab.com/fedora/people) a private group with one repo in it
We likely need to ask that person about where to move these or keep them.
This might have to be something that we have a meeting to discuss and figure out a scheme?
Sure, or the scheme below seems good to me.
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
Oh, i can also definitely get on board with a set scheme for Fedora Accounts groups <-> Gitlab Groups naming conventions.
Yeah, +1
However, the one of the main issues i am noticing with our current GitLab setup is that the groups that are being added are being done in an adhoc setting.
For example, there are groups for Council and Mindshare (and not yet, but i can imagine a FesCO group too) -- should these be grouped together under, say a "Governance" Sub group?
cheers, ryanlerch
Multiple solutions : one can always create new groups and reflect that at gitlab level (same membership but different group name[s]) and IPA supports multiple "nesting" levels so you can (in your Governance example) have one groups containining/nesting multiple other ones
Yeah, or 'project' instead of 'govenance'?
We should write up a doc with whatever we do to document it and make sure everything is on the same page.
kevin
On 8/7/23 13:04, Kevin Fenzi wrote: <snip>
This might have to be something that we have a meeting to discuss and figure out a scheme?
Sure, or the scheme below seems good to me.
cheers, ryanlerch
Hi Ryan,
We more or less discussed that with Kevin in the past and for CentOS groups (all coming from same common IPA infra) I proposed that we used something like : <target>-<project>-<group_name>
Let me explain : Assuming that we need to grant the CentOS Automotive SIG access to gitlab, the name in FAS/IPA is : gitlab-centos-sig-automotive-developer (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-develo...)
Same rule but for openshift/ocp : we need to grant the hyperscale sig access to the openshift CI centos infra : https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
It's then easier to identify which group has access to what (gitlab/openshift/etc) *while* keeping the existing groups, as IPA supports nested groups (so the ocp-cico-hyperscale group in fact contains the sig-hyperscale group (https://accounts.fedoraproject.org/group/sig-hyperscale/)
At least that's the naming convention we agreed on so that we can also easily identify if that's a fedora/centos group (all the sig-* groups weren't following that naming convention as they were coming from previous FAS and so imported/merged with the fedora groups in IPA, but there was no conflicting group back then)
Oh, i can also definitely get on board with a set scheme for Fedora Accounts groups <-> Gitlab Groups naming conventions.
Yeah, +1
However, the one of the main issues i am noticing with our current GitLab setup is that the groups that are being added are being done in an adhoc setting.
For example, there are groups for Council and Mindshare (and not yet, but i can imagine a FesCO group too) -- should these be grouped together under, say a "Governance" Sub group?
cheers, ryanlerch
Multiple solutions : one can always create new groups and reflect that at gitlab level (same membership but different group name[s]) and IPA supports multiple "nesting" levels so you can (in your Governance example) have one groups containining/nesting multiple other ones
Yeah, or 'project' instead of 'govenance'?
We should write up a doc with whatever we do to document it and make sure everything is on the same page.
kevin
Has there been a conclusion to this? The AI/ML SIG is looking to request a FAS group to manage access to the sigs/ai-ml project in GitLab but we're not sure what to request for a name.
Thanks,
Tim
On Tue, Aug 15, 2023 at 03:06:36PM -0600, Tim Flink wrote:
Has there been a conclusion to this? The AI/ML SIG is looking to request a FAS group to manage access to the sigs/ai-ml project in GitLab but we're not sure what to request for a name.
Thanks,
Tim
Somehow I didn't notice this email until just now. ;(
I think we should adopt the naming that fabian suggests upthread. So, you would have:
gitlab-fedora-ai-ml-admin -> admin users
gitlab-fedora-ai-ml-developers -> developer users
etc.
At least I think that makes sense...
kevin
infrastructure@lists.fedoraproject.org
-
Fabian Arrotin -
Kevin Fenzi -
Michal Konecny -
Ryan Lerch -
Tim Flink