#10763 Packit permissions
Closed: Will Not/Can Not fix 2 years ago by mmassari. Opened 2 years ago by mmassari.

I am Maja from the Packit team.
We are now able to automatically release a package going through the phases of submitting a dist-git PR, creating a Koji build and a Bodhi update on behalf of a packager but the Packit Bot needs
- to belong to the packager group
- to be granted the commit access level for every package it releases to be able to do the Bodhi updates.
We would like to get rid of the commit access level.
We assumed we need it based on our experience: we can not manage to create a Bodhi update with lower access levels, but there is no documentation - or at least we could not find it - which describe this constraint and since Packit belongs to the packager group we can already do a Koji build for every package without asking further permissions.
The Packit Bot does not have to commit into the package dist-git repo thus it sounds dangerous to ask for having such a permission.

One of the following solutions could help us:
1. have an ad hoc permission setting just to enable the creation of Bodhi updates
2. give to the collaborator or ticket access level the permission to create Bodhi updates
3. give to Packit the permission to create Bodhi updates for every package but the maintainer must enable this behaviour manually through a setting.

Ideally, we would also like getting rid of the packager group status for the Packit Bot because now our Bot has permissions which it does not need.
However we think that to let Packit do what it is already doing without being a packager anymore is quite a challenging feature request.
For this reason we kindly ask you to solve the commit access level problems related with the Bodhi updates.
But if for any reason this (or Packit's permissions in general) could be done in a simple way also getting rid of the packager group status for Packit then we would follow this way.

Let me know if you have any questions or if I can do something to help,

Maja


Metadata Update from @phsmoura:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago

Would it be better to discuss this over a videocall to understand the requirement?

Well, I think this is possible, but this might be the wrong place to discuss it. It seems like changes need to happen in bodhi.
So, perhaps we should refile there? https://github.com/fedora-infra/bodhi/

Since this isn't something that logs of things should need perhaps it could just be an exception in the bodhi config that we could add packit to?

@kevin, thanks for getting back to us.

We initially wanted to know if something like this would be possible and if we'd need approval from FESCO or some other body.

We can file a concrete request in bodhi upstream and work from there.

It's probibly a good idea to run it by fesco indeed. However, I think it might be best to discuss with bodhi developers first how practical it will be to implement and what constraints there might be.

So, shall we continue in a bodhi issue and close this one?

I have just created this issue: https://github.com/fedora-infra/bodhi/issues/4671.

I am going to close this one.

Thank you kevin for your help.

Metadata Update from @mmassari:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

2 years ago

Hello!

Sorry for commenting on a closed issue, but here is an outcome from the Bodhi ticket:

  • One option (hopefully easy to do) is to create a new FAS group for users (or bots) that are able to create updates for any project.
    • With this, Packit can avoid having commit rights for the packages that wants Bodhi updates to be created by Packit. On the other hand, we will be able to create updates for any package.
    • What should be done to let this happen? Who and how should we ask for this group and Packit to be added there?
  • Second option is to have a per-package way in a dist-git setting to let someone create updates. (E.g. by adding a new access level, or a separate field.)
    • This will be ideal from the Packit's perspective -- explicit approval and no extra unneeded permissions.
    • But. It does not look like an easy task to do. Or?

Note that we have a working solution for now but are asking for an ideal long-term solution with as less unneeded power as possible...

Hello!

Sorry for commenting on a closed issue, but here is an outcome from the Bodhi ticket:

  • One option (hopefully easy to do) is to create a new FAS group for users (or bots) that are able to create updates for any project.
  • With this, Packit can avoid having commit rights for the packages that wants Bodhi updates to be created by Packit. On the other hand, we will be able to create updates for any package.
  • What should be done to let this happen? Who and how should we ask for this group and Packit to be added there?

Just a infra ticket (open a new one, or reopen this one)?

I guess we could call it 'ci-bots' or 'automation-users' or something?

  • Second option is to have a per-package way in a dist-git setting to let someone create updates. (E.g. by adding a new access level, or a separate field.)
  • This will be ideal from the Packit's perspective -- explicit approval and no extra unneeded permissions.
  • But. It does not look like an easy task to do. Or?

This would be a ton of work I think (modifying pagure, etc).

Just a infra ticket (open a new one, or reopen this one)?

I've created a new one: #10959

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog