GitLab AMA Topic Discussion: Permissions & Access

[Aoife Moloney]

Hi everyone,

Thanks again for your involvement in the GitLab AMA session on IRC in
September. As promised, this is the first of a 5-part series breaking
down main topics that came up during the session. I will send a topic
every week for discussion to both Fedora and CentOS devel lists. I
have pulled the relevant questions and answers from the original
hackmd doc into one email. If you would like to discuss this topic
specifically, here might be a good place to do so. I dont consider
myself technical enough to weigh in on details, but I am happy to
facilitate as best I can via email. And more importantly (for me),
learn from the discussion too.

Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view

## Topic: Permission and Access

- Question: Fedora has a group-based access system. People in the
`packager` group have (commit) access to only the packages they
maintain. People in the `provenpackager` group have (commit) access to
all the active packages, but a few (for legal reason). People in the
`releng` group have commit access to all the packages. Is this an
access model that GitLab can support? If not, how would this work in a
GitLab world? How would notifications work (Esp consider people in the
`provenpackager` or `releng` group do not want to be notified for all
the projects they have access to)?
    - Answer: What I explored was something along the lines of :
        - Packager → Using GitLab’s Maintainer or Developer role for
the project they maintain (Maintainer have the ability to access
project settings and change pretty much everything there, so that
might be blocking here, Developer only have commit access, so we need
another way to change some settings for Packagers)
        - Co-Maintainer → Using GitLab’s Developer role (commit access)
        - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
        - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
        - This is not an exact matching with what we currently have
but should give us a way to experiment with this and look at what is
acceptable or not.
        - There is also a GitLab ticket
(https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
policies for the project that could give more granular control of
permissions.
        - Gitlab’s notifications are quite granular and can be managed
at the different levels (Merge Requests, Projects, Group, Global)
https://docs.gitlab.com/ee/user/profile/notifications.html#global-notific...


- Question: Fedora supports the concept of a retired `project` (ie:
archived) that no-one can commit to. Does GitLab have an equivalent
concept? (The retired status is not something project admins can
change)
    - Answer: There is an option to have a “retired” group which is
configured to have nobody with commit access. Then retiring a project
would simply mean to move the project from the “rpm” group to
“retired” group for example.
There is also possibility to simply archive projects
https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project

- Question: could gitlab (inc) maintain a Community Edition GitLab
instance that Fedora uses?
    - Answer: There is no plan to create custom versions of GitLab for
customers. Instead, GitLab encourages paid customers and free users
alike to contribute upstream to make sure that GitLab continues to
work well for the most amount of users possible. As an open core
company, GitLab has a public roadmap and works with its community
members to build a great product.
GitLab regularly engages with its community and takes into account its
feedback. As a result, features are often ported down into lower tiers
in order to make the Community Edition and Free tiers continuously
more useful (see example of 18 features moved to open source). GitLab
hosting is available to users of GitLab.com SaaS, but GitLab does not
offer hosting and management for GitLab CE or EE instances.

- Question: Can project creation be restricted to a specific group of
people in GitLab?
    - Answer: Yes this can be configured at the instance level
(https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
or at the group level
(https://gitlab.com/help/user/group/index.md#default-project-creation-level)

- Question: Can project (main project, not fork) deletion be
restricted to a specific group of people in GitLab? (ie: project
owner/maintainer must not be allowed to delete a main project, they
can delete their own fork of course)
    - Answer: There is an issue
https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
with this by requiring an additional person approve the deletion &
there’s a related issue
https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
of authorized approvers for these types of changes (not MRs) that
sounds aligned with this ask

- Question: How would group membership be sync to GitLab?
    - Answer: We are still not 100% clear on that, since GitLab
supports OpenIDC & we will need to investigate if we could make use of
the group scope returned by AAA. Otherwise we will need a solution to
sync the groups to GitLab most likely using API calls.

 - Question:Will there be better support for Podman in CI workflows in GitLab?
    - Answer: Short term solution might be using a custom executor,
long term solution would be getting the Runner executor podman (#4185)
feature request issue scheduled and closed. Ultimately product team
schedules work, while everyone can contribute MRs or fixes ahead of
schedule. In the past, I've seen a lot of enthusiasm from GitLab team
members in helping solve problems from Open Source Program members
whenever possible.

These are all the questions that had answers I could spot from the
larger hackmd document, however my apologies if I missed any.
next week I will pull in all the questions and answers on 'Message
Bus' in a new email and send for discussion.
I know there are still some questions unanswered so I will try to
chase down answers to these, but it could take some time. If I can get
them answered over the next few weeks, I will send a 'misc' topic
email at the end of these few weeks worth of emails.


I hope you find this helpful and it is going to take some time to work
through everything so thank you for your patience and involvement in
this, it is very much appreciated.



Kindest regards,
Aoife
-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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/[e-mail]...

[Pierre-Yves Chibon]

On Sun, Oct 25, 2020 at 09:17:04PM +0000, Aoife Moloney wrote:
>  Hi everyone,
>  
>  Thanks again for your involvement in the GitLab AMA session on IRC in
>  September. As promised, this is the first of a 5-part series breaking
>  down main topics that came up during the session. I will send a topic
>  every week for discussion to both Fedora and CentOS devel lists. I
>  have pulled the relevant questions and answers from the original
>  hackmd doc into one email. If you would like to discuss this topic
>  specifically, here might be a good place to do so. I dont consider
>  myself technical enough to weigh in on details, but I am happy to
>  facilitate as best I can via email. And more importantly (for me),
>  learn from the discussion too.
>  
>  Here are some links to resources as well:
>  * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
>  * Chat log from session
>
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
>  * AMA Blog post
>  https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
>  * Here is this email in hackmd if you wish to view it there:
>  https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
>  
>  ## Topic: Permission and Access
>  
>  - Question: Fedora has a group-based access system. People in the
>  `packager` group have (commit) access to only the packages they
>  maintain. People in the `provenpackager` group have (commit) access to
>  all the active packages, but a few (for legal reason). People in the
>  `releng` group have commit access to all the packages. Is this an
>  access model that GitLab can support? If not, how would this work in a
>  GitLab world? How would notifications work (Esp consider people in the
>  `provenpackager` or `releng` group do not want to be notified for all
>  the projects they have access to)?
>      - Answer: What I explored was something along the lines of :
>          - Packager → Using GitLab’s Maintainer or Developer role for
>  the project they maintain (Maintainer have the ability to access
>  project settings and change pretty much everything there, so that
>  might be blocking here, Developer only have commit access, so we need
>  another way to change some settings for Packagers) 
Considering the amount of settings we do not want packagers to change
(no-force-push, no-deletion, no FXX branch creation...), I agree that giving
maintainer access is likely not going to work for us and therefore it'll have to
be 'developer' access.

>          - Co-Maintainer → Using GitLab’s Developer role (commit
> access)
>          - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
>          - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
>          - This is not an exact matching with what we currently have
>  but should give us a way to experiment with this and look at what is
>  acceptable or not.
>          - There is also a GitLab ticket
>  (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
>  policies for the project that could give more granular control of
>  permissions. 
So if this gets implemented, we would be able to pick and choose which settings
are available to developer and which are available to admins only, is that
correct?

What about the default point of contact. We need one packager to be the default
point of contact in bugzilla for every project/package. Currently we assume the
main-admin is that point of contact unless told otherwise via the bugzilla
overrides.
How would this work in a gitlab model if all the maintainers are at developer
level?
 
>  - Question: Fedora supports the concept of a retired `project` (ie:
>  archived) that no-one can commit to. Does GitLab have an equivalent
>  concept? (The retired status is not something project admins can
>  change)
>      - Answer: There is an option to have a “retired” group which is
>  configured to have nobody with commit access. Then retiring a project
>  would simply mean to move the project from the “rpm” group to
>  “retired” group for example.
>  There is also possibility to simply archive projects
>  https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project 
Does that mean that the URL of the project will change? (or are there redirects
that are automatically created?)
What if rpms/cockpit and container/cockpit both get retired? Can we do
retired/rpms/cockpit and retired/container/cockpit? Or should we do
retired/rpms_cockpit and retired/container_cockpit?

I figure only admins can move project between groups or archive/unarchive
projects. That means we'll need a way for packagers to indicate their wish to
retire a project and then a bot to actually do it.

>  - Question: could gitlab (inc) maintain a Community Edition GitLab
>  instance that Fedora uses?
>      - Answer: There is no plan to create custom versions of GitLab for
>  customers. Instead, GitLab encourages paid customers and free users
>  alike to contribute upstream to make sure that GitLab continues to
>  work well for the most amount of users possible. As an open core
>  company, GitLab has a public roadmap and works with its community
>  members to build a great product.
>  GitLab regularly engages with its community and takes into account its
>  feedback. As a result, features are often ported down into lower tiers
>  in order to make the Community Edition and Free tiers continuously
>  more useful (see example of 18 features moved to open source). GitLab
>  hosting is available to users of GitLab.com SaaS, but GitLab does not
>  offer hosting and management for GitLab CE or EE instances. 
So, if I understand this correctly it means we have the choice between:
- self-hosting a gitlab instance
- have a dedicate space on gitlab.com

Is that correct?

>  - Question: Can project creation be restricted to a specific group
> of
>  people in GitLab?
>      - Answer: Yes this can be configured at the instance level
>
> (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
>  or at the group level
>  (https://gitlab.com/help/user/group/index.md#default-project-creation-level) 
Does the instance level override the group level one? If not can group admins
change this setting?
If so, is there an access level in groups that allows to add/remove people from
a group without being allowed to toggle that setting?

In other words, can we let the groups self-managed without "risking" someone
changing this configuration? Or do we need to figure out a process to add/remove
people to groups? (Like a ticketing system that is automatically process by a
bot)

>  - Question: Can project (main project, not fork) deletion be
>  restricted to a specific group of people in GitLab? (ie: project
>  owner/maintainer must not be allowed to delete a main project, they
>  can delete their own fork of course)
>      - Answer: There is an issue
>  https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
>  with this by requiring an additional person approve the deletion &
>  there’s a related issue
>  https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
>  of authorized approvers for these types of changes (not MRs) that
>  sounds aligned with this ask 
So we would need an admin person to delete a main project, that sounds fine.
What about forks though? Would we be able to let user delete their own fork
without supervision?

>  - Question: How would group membership be sync to GitLab?
>      - Answer: We are still not 100% clear on that, since GitLab
>  supports OpenIDC & we will need to investigate if we could make use of
>  the group scope returned by AAA. Otherwise we will need a solution to
>  sync the groups to GitLab most likely using API calls. 
 
 
>  I hope you find this helpful and it is going to take some time to
> work
>  through everything so thank you for your patience and involvement in
>  this, it is very much appreciated. 
Thanks for opening the discussion! :)


Pierre

[Matthew Miller]

On Wed, Oct 28, 2020 at 01:57:14PM +0100, Pierre-Yves Chibon wrote:
>  > - Question: could gitlab (inc) maintain a Community Edition
> GitLab
>  > instance that Fedora uses? 
[...]
>  So, if I understand this correctly it means we have the choice
> between:
>  - self-hosting a gitlab instance
>  - have a dedicate space on gitlab.com 
Or possibly pay a third-party hosting site to run Gitlab CE for us.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Wed, Oct 28, 2020 at 8:57 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  On Sun, Oct 25, 2020 at 09:17:04PM +0000, Aoife Moloney wrote:
>  > Hi everyone,
>  >
>  > Thanks again for your involvement in the GitLab AMA session on IRC in
>  > September. As promised, this is the first of a 5-part series breaking
>  > down main topics that came up during the session. I will send a topic
>  > every week for discussion to both Fedora and CentOS devel lists. I
>  > have pulled the relevant questions and answers from the original
>  > hackmd doc into one email. If you would like to discuss this topic
>  > specifically, here might be a good place to do so. I dont consider
>  > myself technical enough to weigh in on details, but I am happy to
>  > facilitate as best I can via email. And more importantly (for me),
>  > learn from the discussion too.
>  >
>  > Here are some links to resources as well:
>  > * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
>  > * Chat log from session
>  >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
>  > * AMA Blog post
>  > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
>  > * Here is this email in hackmd if you wish to view it there:
>  > https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
>  >
>  > ## Topic: Permission and Access
>  >
>  > - Question: Fedora has a group-based access system. People in the
>  > `packager` group have (commit) access to only the packages they
>  > maintain. People in the `provenpackager` group have (commit) access to
>  > all the active packages, but a few (for legal reason). People in the
>  > `releng` group have commit access to all the packages. Is this an
>  > access model that GitLab can support? If not, how would this work in a
>  > GitLab world? How would notifications work (Esp consider people in the
>  > `provenpackager` or `releng` group do not want to be notified for all
>  > the projects they have access to)?
>  >     - Answer: What I explored was something along the lines of :
>  >         - Packager → Using GitLab’s Maintainer or Developer role for
>  > the project they maintain (Maintainer have the ability to access
>  > project settings and change pretty much everything there, so that
>  > might be blocking here, Developer only have commit access, so we need
>  > another way to change some settings for Packagers)
>
>  Considering the amount of settings we do not want packagers to change
>  (no-force-push, no-deletion, no FXX branch creation...), I agree that giving
>  maintainer access is likely not going to work for us and therefore it'll have to
>  be 'developer' access.
>
>  >         - Co-Maintainer → Using GitLab’s Developer role (commit access)
>  >         - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
>  >         - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
>  >         - This is not an exact matching with what we currently have
>  > but should give us a way to experiment with this and look at what is
>  > acceptable or not.
>  >         - There is also a GitLab ticket
>  > (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
>  > policies for the project that could give more granular control of
>  > permissions.
>
>  So if this gets implemented, we would be able to pick and choose which settings
>  are available to developer and which are available to admins only, is that
>  correct?
>  
Maybe. I've been burned by GitLab scoping out all the actual things me
and others ask for and building features that nobody wants and doesn't
do enough. The Epic that replaced that issue
(https://gitlab.com/groups/gitlab-org/-/epics/4168) seems to indicate
that the implementation will mainly offer label and archive control
and not much else.

>  What about the default point of contact. We need one packager to be
> the default
>  point of contact in bugzilla for every project/package. Currently we assume the
>  main-admin is that point of contact unless told otherwise via the bugzilla
>  overrides.
>  How would this work in a gitlab model if all the maintainers are at developer
>  level?
>  
It won't. You'd need a separate application to maintain that information.

>  > - Question: Fedora supports the concept of a retired `project`
> (ie:
>  > archived) that no-one can commit to. Does GitLab have an equivalent
>  > concept? (The retired status is not something project admins can
>  > change)
>  >     - Answer: There is an option to have a “retired” group which is
>  > configured to have nobody with commit access. Then retiring a project
>  > would simply mean to move the project from the “rpm” group to
>  > “retired” group for example.
>  > There is also possibility to simply archive projects
>  > https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project
>
>  Does that mean that the URL of the project will change? (or are there redirects
>  that are automatically created?)
>  What if rpms/cockpit and container/cockpit both get retired? Can we do
>  retired/rpms/cockpit and retired/container/cockpit? Or should we do
>  retired/rpms_cockpit and retired/container_cockpit?
>  
The URL would change, there would automatically be redirects when
projects are moved (though this is glitchy and has a few caveats).

>  I figure only admins can move project between groups or
> archive/unarchive
>  projects. That means we'll need a way for packagers to indicate their wish to
>  retire a project and then a bot to actually do it.
>  
Maintainer level and above can archive projects, since that means they
have access to project settings. They also can move projects across
groups that they have project creation rights (maintainer or above)
in.

>  > - Question: could gitlab (inc) maintain a Community Edition
> GitLab
>  > instance that Fedora uses?
>  >     - Answer: There is no plan to create custom versions of GitLab for
>  > customers. Instead, GitLab encourages paid customers and free users
>  > alike to contribute upstream to make sure that GitLab continues to
>  > work well for the most amount of users possible. As an open core
>  > company, GitLab has a public roadmap and works with its community
>  > members to build a great product.
>  > GitLab regularly engages with its community and takes into account its
>  > feedback. As a result, features are often ported down into lower tiers
>  > in order to make the Community Edition and Free tiers continuously
>  > more useful (see example of 18 features moved to open source). GitLab
>  > hosting is available to users of GitLab.com SaaS, but GitLab does not
>  > offer hosting and management for GitLab CE or EE instances.
>
>  So, if I understand this correctly it means we have the choice between:
>  - self-hosting a gitlab instance
>  - have a dedicate space on gitlab.com
>
>  Is that correct?
>  
This is correct. GitLab discontinued their dedicated hosting offering
(githost.io) last year to focus on the GitLab.com SaaS offering based
on GitLab Ultimate.

>  > - Question: Can project creation be restricted to a specific
> group of
>  > people in GitLab?
>  >     - Answer: Yes this can be configured at the instance level
>  >
> (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
>  > or at the group level
>  > (https://gitlab.com/help/user/group/index.md#default-project-creation-level)
>
>  Does the instance level override the group level one? If not can group admins
>  change this setting?
>  If so, is there an access level in groups that allows to add/remove people from
>  a group without being allowed to toggle that setting?
>
>  In other words, can we let the groups self-managed without "risking" someone
>  changing this configuration? Or do we need to figure out a process to add/remove
>  people to groups? (Like a ticketing system that is automatically process by a
>  bot)
>  
The inheritance order for most settings (in my experience) indicates
that project settings override instance settings (as they are only
defaults). For example, if you configure CI or issue tracking as off
in the instance wide settings, projects can override this and turn
them back on. Same goes for artifact archiving policies and other
instance level settings for projects.

>  > - Question: Can project (main project, not fork) deletion be
>  > restricted to a specific group of people in GitLab? (ie: project
>  > owner/maintainer must not be allowed to delete a main project, they
>  > can delete their own fork of course)
>  >     - Answer: There is an issue
>  > https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
>  > with this by requiring an additional person approve the deletion &
>  > there’s a related issue
>  > https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
>  > of authorized approvers for these types of changes (not MRs) that
>  > sounds aligned with this ask
>
>  So we would need an admin person to delete a main project, that sounds fine.
>  What about forks though? Would we be able to let user delete their own fork
>  without supervision?
>  
Forks are not special in GitLab like they are in Pagure, so rules
applied to main projects will apply to forks.

>  > - Question: How would group membership be sync to GitLab?
>  >     - Answer: We are still not 100% clear on that, since GitLab
>  > supports OpenIDC & we will need to investigate if we could make use of
>  > the group scope returned by AAA. Otherwise we will need a solution to
>  > sync the groups to GitLab most likely using API calls.
>  
In my experience, you're going to need an application to sync them
using the GitLab API.

>  > I hope you find this helpful and it is going to take some time to work
>  > through everything so thank you for your patience and involvement in
>  > this, it is very much appreciated.
>
>  Thanks for opening the discussion! :)
>  
Indeed.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Pierre-Yves Chibon]

On Wed, Oct 28, 2020 at 09:56:11AM -0400, Neal Gompa wrote:
>  On Wed, Oct 28, 2020 at 8:57 AM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
>  >
>  > On Sun, Oct 25, 2020 at 09:17:04PM +0000, Aoife Moloney wrote:
>  > > Hi everyone,
>  > >
>  > > Thanks again for your involvement in the GitLab AMA session on IRC in
>  > > September. As promised, this is the first of a 5-part series breaking
>  > > down main topics that came up during the session. I will send a topic
>  > > every week for discussion to both Fedora and CentOS devel lists. I
>  > > have pulled the relevant questions and answers from the original
>  > > hackmd doc into one email. If you would like to discuss this topic
>  > > specifically, here might be a good place to do so. I dont consider
>  > > myself technical enough to weigh in on details, but I am happy to
>  > > facilitate as best I can via email. And more importantly (for me),
>  > > learn from the discussion too.
>  > >
>  > > Here are some links to resources as well:
>  > > * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
>  > > * Chat log from session
>  > >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
>  > > * AMA Blog post
>  > > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
>  > > * Here is this email in hackmd if you wish to view it there:
>  > > https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
>  > >
>  > > ## Topic: Permission and Access
>  > >
>  > > - Question: Fedora has a group-based access system. People in the
>  > > `packager` group have (commit) access to only the packages they
>  > > maintain. People in the `provenpackager` group have (commit) access to
>  > > all the active packages, but a few (for legal reason). People in the
>  > > `releng` group have commit access to all the packages. Is this an
>  > > access model that GitLab can support? If not, how would this work in a
>  > > GitLab world? How would notifications work (Esp consider people in the
>  > > `provenpackager` or `releng` group do not want to be notified for all
>  > > the projects they have access to)?
>  > >     - Answer: What I explored was something along the lines of :
>  > >         - Packager → Using GitLab’s Maintainer or Developer role for
>  > > the project they maintain (Maintainer have the ability to access
>  > > project settings and change pretty much everything there, so that
>  > > might be blocking here, Developer only have commit access, so we need
>  > > another way to change some settings for Packagers)
>  >
>  > Considering the amount of settings we do not want packagers to change
>  > (no-force-push, no-deletion, no FXX branch creation...), I agree that giving
>  > maintainer access is likely not going to work for us and therefore it'll have
> to
>  > be 'developer' access.
>  >
>  > >         - Co-Maintainer → Using GitLab’s Developer role (commit access)
>  > >         - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
>  > >         - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
>  > >         - This is not an exact matching with what we currently have
>  > > but should give us a way to experiment with this and look at what is
>  > > acceptable or not.
>  > >         - There is also a GitLab ticket
>  > > (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
>  > > policies for the project that could give more granular control of
>  > > permissions.
>  >
>  > So if this gets implemented, we would be able to pick and choose which settings
>  > are available to developer and which are available to admins only, is that
>  > correct?
>  >
>  
>  Maybe. I've been burned by GitLab scoping out all the actual things me
>  and others ask for and building features that nobody wants and doesn't
>  do enough. The Epic that replaced that issue
>  (https://gitlab.com/groups/gitlab-org/-/epics/4168) seems to indicate
>  that the implementation will mainly offer label and archive control
>  and not much else. 
So if this ticket/epic does not get us what we want, we'll need a proxy service
to add/remove users/groups to a project?
 
>  > > - Question: Fedora supports the concept of a retired
> `project` (ie:
>  > > archived) that no-one can commit to. Does GitLab have an equivalent
>  > > concept? (The retired status is not something project admins can
>  > > change)
>  > >     - Answer: There is an option to have a “retired” group which is
>  > > configured to have nobody with commit access. Then retiring a project
>  > > would simply mean to move the project from the “rpm” group to
>  > > “retired” group for example.
>  > > There is also possibility to simply archive projects
>  > > https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project
>  >
>  > Does that mean that the URL of the project will change? (or are there redirects
>  > that are automatically created?)
>  > What if rpms/cockpit and container/cockpit both get retired? Can we do
>  > retired/rpms/cockpit and retired/container/cockpit? Or should we do
>  > retired/rpms_cockpit and retired/container_cockpit?
>  >
>  
>  The URL would change, there would automatically be redirects when
>  projects are moved (though this is glitchy and has a few caveats). 
May we assume the redirects work in both direction and clean themselves?

As in, upon retirement: rpms/cockpit -> retired/rpms/cockpit
and upon un-retirement: retired/rpms/cockpit -> rpms/cockpit (w/ the first
redirect being removed to avoid looping (been there, done that...))

>  > I figure only admins can move project between groups or
> archive/unarchive
>  > projects. That means we'll need a way for packagers to indicate their wish to
>  > retire a project and then a bot to actually do it.
>  >
>  
>  Maintainer level and above can archive projects, since that means they
>  have access to project settings. They also can move projects across
>  groups that they have project creation rights (maintainer or above)
>  in. 
Sorry I phrased this incorrectly. It assumed that only admins have access to
maintainer level and above (based on the first section that we cannot have
packager have more than the developer level).

Thanks for pointing this out.

The point about needed automation through a proxy still stands though, no?

>  > > - Question: Can project creation be restricted to a
> specific group of
>  > > people in GitLab?
>  > >     - Answer: Yes this can be configured at the instance level
>  > >
> (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
>  > > or at the group level
>  > > (https://gitlab.com/help/user/group/index.md#default-project-creation-level)
>  >
>  > Does the instance level override the group level one? If not can group admins
>  > change this setting?
>  > If so, is there an access level in groups that allows to add/remove people from
>  > a group without being allowed to toggle that setting?
>  >
>  > In other words, can we let the groups self-managed without "risking"
> someone
>  > changing this configuration? Or do we need to figure out a process to add/remove
>  > people to groups? (Like a ticketing system that is automatically process by a
>  > bot)
>  >
>  
>  The inheritance order for most settings (in my experience) indicates
>  that project settings override instance settings (as they are only
>  defaults). For example, if you configure CI or issue tracking as off
>  in the instance wide settings, projects can override this and turn
>  them back on. Same goes for artifact archiving policies and other
>  instance level settings for projects. 
So another proxy needed to add/remove people from a group then I guess?

>  > > - Question: Can project (main project, not fork) deletion
> be
>  > > restricted to a specific group of people in GitLab? (ie: project
>  > > owner/maintainer must not be allowed to delete a main project, they
>  > > can delete their own fork of course)
>  > >     - Answer: There is an issue
>  > > https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
>  > > with this by requiring an additional person approve the deletion &
>  > > there’s a related issue
>  > > https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
>  > > of authorized approvers for these types of changes (not MRs) that
>  > > sounds aligned with this ask
>  >
>  > So we would need an admin person to delete a main project, that sounds fine.
>  > What about forks though? Would we be able to let user delete their own fork
>  > without supervision?
>  >
>  
>  Forks are not special in GitLab like they are in Pagure, so rules
>  applied to main projects will apply to forks. 
I'm starting to think that disabling project deletion to everyone but admins
and have another proxy service that let people request their fork to be deleted
may also be the way forward here.



Pierre

[Neal Gompa]

On Wed, Oct 28, 2020 at 10:10 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  On Wed, Oct 28, 2020 at 09:56:11AM -0400, Neal Gompa wrote:
>  > On Wed, Oct 28, 2020 at 8:57 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;
> wrote:
>  > >
>  > > On Sun, Oct 25, 2020 at 09:17:04PM +0000, Aoife Moloney wrote:
>  > > > Hi everyone,
>  > > >
>  > > > Thanks again for your involvement in the GitLab AMA session on IRC in
>  > > > September. As promised, this is the first of a 5-part series breaking
>  > > > down main topics that came up during the session. I will send a topic
>  > > > every week for discussion to both Fedora and CentOS devel lists. I
>  > > > have pulled the relevant questions and answers from the original
>  > > > hackmd doc into one email. If you would like to discuss this topic
>  > > > specifically, here might be a good place to do so. I dont consider
>  > > > myself technical enough to weigh in on details, but I am happy to
>  > > > facilitate as best I can via email. And more importantly (for me),
>  > > > learn from the discussion too.
>  > > >
>  > > > Here are some links to resources as well:
>  > > > * Questions and Answers hackmd link
> https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
>  > > > * Chat log from session
>  > > >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
>  > > > * AMA Blog post
>  > > > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
>  > > > * Here is this email in hackmd if you wish to view it there:
>  > > > https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
>  > > >
>  > > > ## Topic: Permission and Access
>  > > >
>  > > > - Question: Fedora has a group-based access system. People in the
>  > > > `packager` group have (commit) access to only the packages they
>  > > > maintain. People in the `provenpackager` group have (commit) access to
>  > > > all the active packages, but a few (for legal reason). People in the
>  > > > `releng` group have commit access to all the packages. Is this an
>  > > > access model that GitLab can support? If not, how would this work in a
>  > > > GitLab world? How would notifications work (Esp consider people in the
>  > > > `provenpackager` or `releng` group do not want to be notified for all
>  > > > the projects they have access to)?
>  > > >     - Answer: What I explored was something along the lines of :
>  > > >         - Packager → Using GitLab’s Maintainer or Developer role for
>  > > > the project they maintain (Maintainer have the ability to access
>  > > > project settings and change pretty much everything there, so that
>  > > > might be blocking here, Developer only have commit access, so we need
>  > > > another way to change some settings for Packagers)
>  > >
>  > > Considering the amount of settings we do not want packagers to change
>  > > (no-force-push, no-deletion, no FXX branch creation...), I agree that giving
>  > > maintainer access is likely not going to work for us and therefore it'll
> have to
>  > > be 'developer' access.
>  > >
>  > > >         - Co-Maintainer → Using GitLab’s Developer role (commit access)
>  > > >         - Proven-Packager → GitLab’s Developer role on all repo (expect
> 2)
>  > > >         - Release Engineer/Admin/etc .. → GitLab’s Owner role on all
> repos
>  > > >         - This is not an exact matching with what we currently have
>  > > > but should give us a way to experiment with this and look at what is
>  > > > acceptable or not.
>  > > >         - There is also a GitLab ticket
>  > > > (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
>  > > > policies for the project that could give more granular control of
>  > > > permissions.
>  > >
>  > > So if this gets implemented, we would be able to pick and choose which
> settings
>  > > are available to developer and which are available to admins only, is that
>  > > correct?
>  > >
>  >
>  > Maybe. I've been burned by GitLab scoping out all the actual things me
>  > and others ask for and building features that nobody wants and doesn't
>  > do enough. The Epic that replaced that issue
>  > (https://gitlab.com/groups/gitlab-org/-/epics/4168) seems to indicate
>  > that the implementation will mainly offer label and archive control
>  > and not much else.
>
>  So if this ticket/epic does not get us what we want, we'll need a proxy service
>  to add/remove users/groups to a project?
>  
Pretty much, yes.

>  > > > - Question: Fedora supports the concept of a retired
> `project` (ie:
>  > > > archived) that no-one can commit to. Does GitLab have an equivalent
>  > > > concept? (The retired status is not something project admins can
>  > > > change)
>  > > >     - Answer: There is an option to have a “retired” group which is
>  > > > configured to have nobody with commit access. Then retiring a project
>  > > > would simply mean to move the project from the “rpm” group to
>  > > > “retired” group for example.
>  > > > There is also possibility to simply archive projects
>  > > > https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project
>  > >
>  > > Does that mean that the URL of the project will change? (or are there
> redirects
>  > > that are automatically created?)
>  > > What if rpms/cockpit and container/cockpit both get retired? Can we do
>  > > retired/rpms/cockpit and retired/container/cockpit? Or should we do
>  > > retired/rpms_cockpit and retired/container_cockpit?
>  > >
>  >
>  > The URL would change, there would automatically be redirects when
>  > projects are moved (though this is glitchy and has a few caveats).
>
>  May we assume the redirects work in both direction and clean themselves?
>
>  As in, upon retirement: rpms/cockpit -> retired/rpms/cockpit
>  and upon un-retirement: retired/rpms/cockpit -> rpms/cockpit (w/ the first
>  redirect being removed to avoid looping (been there, done that...))
>  
In general, this is supposed to work, yes.

>  > > I figure only admins can move project between groups or
> archive/unarchive
>  > > projects. That means we'll need a way for packagers to indicate their wish
> to
>  > > retire a project and then a bot to actually do it.
>  > >
>  >
>  > Maintainer level and above can archive projects, since that means they
>  > have access to project settings. They also can move projects across
>  > groups that they have project creation rights (maintainer or above)
>  > in.
>
>  Sorry I phrased this incorrectly. It assumed that only admins have access to
>  maintainer level and above (based on the first section that we cannot have
>  packager have more than the developer level).
>
>  Thanks for pointing this out.
>
>  The point about needed automation through a proxy still stands though, no?
>  
Yep. Just wanted to clarify what we can actually do here in GitLab itself.

>  > > > - Question: Can project creation be restricted to a
> specific group of
>  > > > people in GitLab?
>  > > >     - Answer: Yes this can be configured at the instance level
>  > > >
> (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
>  > > > or at the group level
>  > > >
> (https://gitlab.com/help/user/group/index.md#default-project-creation-level)
>  > >
>  > > Does the instance level override the group level one? If not can group admins
>  > > change this setting?
>  > > If so, is there an access level in groups that allows to add/remove people
> from
>  > > a group without being allowed to toggle that setting?
>  > >
>  > > In other words, can we let the groups self-managed without "risking"
> someone
>  > > changing this configuration? Or do we need to figure out a process to
> add/remove
>  > > people to groups? (Like a ticketing system that is automatically process by a
>  > > bot)
>  > >
>  >
>  > The inheritance order for most settings (in my experience) indicates
>  > that project settings override instance settings (as they are only
>  > defaults). For example, if you configure CI or issue tracking as off
>  > in the instance wide settings, projects can override this and turn
>  > them back on. Same goes for artifact archiving policies and other
>  > instance level settings for projects.
>
>  So another proxy needed to add/remove people from a group then I guess?
>  
Yep.

>  > > > - Question: Can project (main project, not fork)
> deletion be
>  > > > restricted to a specific group of people in GitLab? (ie: project
>  > > > owner/maintainer must not be allowed to delete a main project, they
>  > > > can delete their own fork of course)
>  > > >     - Answer: There is an issue
>  > > > https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
>  > > > with this by requiring an additional person approve the deletion &
>  > > > there’s a related issue
>  > > > https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
>  > > > of authorized approvers for these types of changes (not MRs) that
>  > > > sounds aligned with this ask
>  > >
>  > > So we would need an admin person to delete a main project, that sounds fine.
>  > > What about forks though? Would we be able to let user delete their own fork
>  > > without supervision?
>  > >
>  >
>  > Forks are not special in GitLab like they are in Pagure, so rules
>  > applied to main projects will apply to forks.
>
>  I'm starting to think that disabling project deletion to everyone but admins
>  and have another proxy service that let people request their fork to be deleted
>  may also be the way forward here.
>  
I think we're looking at having a pkgdb3 web service if we move
forward with GitLab, simply because there's no way to actually
*implement* everything we need in GitLab itself.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Fabio Valentini]

On Wed, Oct 28, 2020 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  
(snip)

>  
> I think we're looking at having a pkgdb3 web service
if we move
> forward with GitLab, simply because there's no way to actually
> *implement* everything we need in GitLab itself.

So ... to me, this does not sound like a good trade-off.

- pagure + pagure-dist-git: well-integrated with other fedora
workflows and tailored to our requirements; possible to develop and
add new features ourselves
- gitlab: little to no integration with other fedora services
possible, proxy / "glue" service (still has to be planned, developed,
and deployed!) required for implementing our workflows and
requirements, probably (temporary?) loss of features compared to
pagure+dist-git, and realistically no influence on GitLab's
development and future direction

Or am I missing something?

Honestly, I'm very worried that just after finally getting back ~all
the features that were "lost" when shutting down pkgdb2 and migrating
to pagure+dist-git, we'll have a major setback *again* when moving to
GitLab, with no clear plan whether we *can* actually get those
features back at all, and no idea how much work implementing those
workflows and requirements on top of GitLab APIs would be.

Fabio

[Mattia Verga]

Il 05/11/20 00:05, Fabio Valentini ha scritto:
>  Honestly, I'm very worried that just after finally getting back ~all
>  the features that were "lost" when shutting down pkgdb2 and migrating
>  to pagure+dist-git, we'll have a major setback *again* when moving to
>  GitLab, with no clear plan whether we *can* actually get those
>  features back at all, and no idea how much work implementing those
>  workflows and requirements on top of GitLab APIs would be.
>  
+1

Well, the entire point of migrating from Pagure to Gitlab was to lower 
the development and maintaining needs of this service, so (sarcastic 
mode on) I would expect all these required changes and proxies to get 
feature parity with Pagure will be developed by Gitlab folks... before 
we migrate.......

Mattia