>>>>
>>>> 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-dev...)
>>>
>>> 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