lachmanfrantisek commented

Hello,

since more and more people use Packit for Fedora automation, we are hitting a problem with notifications being missed because Packit is the one to do the action and not the maintainers themselves. This is currently the main flaw of the whole automation so we are discussing in a Packit team how to improve this.

But this might not relate only to Packit users but anyone in need of notification for events triggered by someone else (i.e. co-maintainer).

There might be various approaches to this and I hope it's good to discuss this with you.

Do this on the Packit's side.
- This does not improve the Fedora notifications in general (i.e. for non-Packit users) and we are creating a secondary place where notifications are tweaked.
Find a way how Packit can impersonate other actors in the Fedora services.
- E.g. similar to the automatic Bodhi updates for Rawhide that are authored by the maintainer and not the Bodhi automation.
- Could be also useful for taking care of the Packit's job results (e.g. editing the Bodhi update without a need to do this manually by a Packit team on request or implementing alternative UX for purpose)
Tweak the notification settings so users can be notified also about package-related events not triggered by myself. (E.g. negative karma of a package I maintain despite me not being the creator of the update).

Describe what you would like us to do:

I would like to agree on an approach so the work on a fix can start.

When do you need this to be done by? (YYYY/MM/DD)

I would like to see the agreement let's say by the end of October. The real work deadlines highly depend on the chosen solution.

If you think it's better to join any of your meetings or create a separate brainstorming session or a discussion thread, I am happy to be present or set this up.
Thanks a lot in advance!
František (from the Packit team)

PS : I've already created an issue for Bodhi about a specific instance of this problem but this is probably better to discuss in general.

Hello, since more and more people use Packit for Fedora automation, we are hitting a problem with notifications being missed because Packit is the one to do the action and not the maintainers themselves. This is currently the main flaw of the whole automation so we are discussing in a Packit team how to improve this. But this might not relate only to Packit users but anyone in need of notification for events triggered by someone else (i.e. co-maintainer). There might be various approaches to this and I hope it's good to discuss this with you. * Do this on the Packit's side. * This does not improve the Fedora notifications in general (i.e. for non-Packit users) and we are creating a secondary place where notifications are tweaked. * Find a way how Packit can impersonate other actors in the Fedora services. * E.g. similar to the automatic Bodhi updates for Rawhide that are authored by the maintainer and not the Bodhi automation. * Could be also useful for taking care of the Packit's job results (e.g. editing the Bodhi update without a need to do this manually by a Packit team on request or implementing alternative UX for purpose) * Tweak the notification settings so users can be notified also about package-related events not triggered by myself. (E.g. negative karma of a package I maintain despite me not being the creator of the update). # Describe what you would like us to do: I would like to agree on an approach so the work on a fix can start. # When do you need this to be done by? (YYYY/MM/DD) I would like to see the agreement let's say by the end of October. The real work deadlines highly depend on the chosen solution. --- If you think it's better to join any of your meetings or create a separate brainstorming session or a discussion thread, I am happy to be present or set this up. Thanks a lot in advance! František (from the Packit team) --- PS : I've already created an [issue for Bodhi](https://github.com/fedora-infra/bodhi/issues/5644) about a specific instance of this problem but this is probably better to discuss in general.

mizdebsk commented

2024-10-09 16:14:06 +00:00

Member

Looks like you are looking for the "proxy user" feature in some services (second bullet)?
Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager.
Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else.
Other services may have it too, I don't remember off the top of my head.
Which services exactly you would expect to have this "proxy user" feature?

Looks like you are looking for the "proxy user" feature in some services (second bullet)? Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager. Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else. Other services may have it too, I don't remember off the top of my head. Which services exactly you would expect to have this "proxy user" feature?

phsmoura commented

2024-10-09 19:04:52 +00:00

Member

Metadata Update from @phsmoura:

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

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

abompard commented

2024-10-10 06:48:23 +00:00

Member

I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here:

agent_name: the FAS username of the person who caused the action
usernames: a list of FAS usernames of people affected by the action

FMN will, by default, notify everybody in usernames except the person in agent_name (unless they selected "Notify me of my own actions").

Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors

So I would suggest using the usernames property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers.
If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in agent_name, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put packit (or None if packit doesn't have a FAS account) in agent_name.

I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here: - `agent_name`: the FAS username of the person who caused the action - `usernames`: a list of FAS usernames of people affected by the action FMN will, by default, notify everybody in `usernames` except the person in `agent_name` (unless they selected "Notify me of my own actions"). Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors So I would suggest using the `usernames` property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers. If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in `agent_name`, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put `packit` (or `None` if packit doesn't have a FAS account) in `agent_name`.

lachmanfrantisek commented

2024-10-10 06:50:32 +00:00

Author

Looks like you are looking for the "proxy user" feature in some services (second bullet)?
Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager.
Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else.
Other services may have it too, I don't remember off the top of my head.

Thanks @mizdebsk for your response. Yes, "proxy user" is a good term for this.

And it's good to know that such a thing already exists in some services. I'll take a look. Thanks for the suggestion.

Which services exactly you would expect to have this "proxy user" feature?

Currently, we mainly communicate with dist-git, Koji and Bodhi. (With dist-git, it's not necessary. )

> Looks like you are looking for the "proxy user" feature in some services (second bullet)? > Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager. > Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else. > Other services may have it too, I don't remember off the top of my head. Thanks @mizdebsk for your response. Yes, "proxy user" is a good term for this. And it's good to know that such a thing already exists in some services. I'll take a look. Thanks for the suggestion. > Which services exactly you would expect to have this "proxy user" feature? Currently, we mainly communicate with dist-git, Koji and Bodhi. (With dist-git, it's not necessary. )

lachmanfrantisek commented

2024-10-10 06:55:28 +00:00

Author

@mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;(

Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process?

@mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;( Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process?

lachmanfrantisek commented

2024-10-10 07:01:55 +00:00

Author

I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here:

agent_name: the FAS username of the person who caused the action

usernames: a list of FAS usernames of people affected by the action

FMN will, by default, notify everybody in usernames except the person in agent_name (unless they selected "Notify me of my own actions").

Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors

So I would suggest using the usernames property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers.
If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in agent_name, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put packit (or None if packit doesn't have a FAS account) in agent_name.

Hello @abompard and thanks for another good pointer!

How can the message-bus message be transformed into a user notification?

Currently, Packit does not send any messages to the bus (we just listen).
So, we should either create our own messages (mostly a duplicate of existing ones from Koji/Bodhi/..), or help with somehow adding the "missing info" to the existing messages from Koji/Bodhi.

> I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here: > > - `agent_name`: the FAS username of the person who caused the action > - `usernames`: a list of FAS usernames of people affected by the action > > FMN will, by default, notify everybody in `usernames` except the person in `agent_name` (unless they selected "Notify me of my own actions"). > > Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors > > So I would suggest using the `usernames` property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers. > If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in `agent_name`, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put `packit` (or `None` if packit doesn't have a FAS account) in `agent_name`. Hello @abompard and thanks for another good pointer! How can the message-bus message be transformed into a user notification? Currently, Packit does not send any messages to the bus (we just listen). So, we should either create our own messages (mostly a duplicate of existing ones from Koji/Bodhi/..), or help with somehow adding the "missing info" to the existing messages from Koji/Bodhi.

mizdebsk commented

2024-10-10 10:08:33 +00:00

Member

@mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;(

In case of Koji, see koji list-api:

sslLogin(*args, **opts)
  description: Login via SSL certificate

    :param str proxyuser: proxy username
    :returns dict: session info

The proxy authenticates to Koji HUB with its own credentials, but during login passes "proxyuser" parameter indicating that the proxy is acting on behalf of someone else.

(The sslLogin method name may be misleading, but it is actually used in Krb auth too.)

Code example: https://pagure.io/fm-orchestrator/c/df594da8a5b28bc5eba5ba89c7661a1381904b10

(It was removed because back then MBS was using SSL auth, but packagers were switched to Krb auth. Nowdays everything should work with Krb.)

Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process?

Koji hub has configuration option that limits who can be a proxy. Once configured, given proxy user can act on behalf of all other users.

Examples of existing use cases of proxy user that are implemented:

packager requests module build in MBS, MBS acting as a proxy submits RPM builds to Koji
packager uses CI dashboard to create waivers, CI dashboard acts as proxy and submits waiver in waiverdb on packagers behalf

> @mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;( In case of Koji, see `koji list-api`: ``` sslLogin(*args, **opts) description: Login via SSL certificate :param str proxyuser: proxy username :returns dict: session info ``` The proxy authenticates to Koji HUB with its own credentials, but during login passes "proxyuser" parameter indicating that the proxy is acting on behalf of someone else. (The sslLogin method name may be misleading, but it is actually used in Krb auth too.) Code example: https://pagure.io/fm-orchestrator/c/df594da8a5b28bc5eba5ba89c7661a1381904b10 (It was removed because back then MBS was using SSL auth, but packagers were switched to Krb auth. Nowdays everything should work with Krb.) > Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process? Koji hub has configuration option that limits who can be a proxy. Once configured, given proxy user can act on behalf of all other users. Examples of existing use cases of proxy user that are implemented: - packager requests module build in MBS, MBS acting as a proxy submits RPM builds to Koji - packager uses CI dashboard to create waivers, CI dashboard acts as proxy and submits waiver in waiverdb on packagers behalf

lachmanfrantisek commented

2024-10-10 10:16:31 +00:00

Author

Thanks @mizdebsk for the examples, these are quite similar to our use case. We would just use the main maintainer (or let the user choose).

If Packit can get this permission, I think that's another reason to have a separate instance and/or FAS account to handle Fedora automation.

Thanks @mizdebsk for the examples, these are quite similar to our use case. We would just use the main maintainer (or let the user choose). If Packit can get this permission, I think that's another reason to have a separate instance and/or FAS account to handle Fedora automation.

kevin commented

2025-02-20 17:37:55 +00:00

Owner

So, where are we here? Whats next actions and done by whom?

lachmanfrantisek commented

2025-02-20 20:32:27 +00:00

Author

Thanks @kevin for the reminder.

I hope we've improved the situation for Packit users to suggest and document how to configure notifications: https://packit.dev/docs/fedora-releases-guide/fedora-notifications

This works quite well and I like that this is not a Packit-specific feature so everyone can do the same. (I.e. people being notified about activities of co-maintainers)

But I still worry this is not ideal since it's not done by default.
So, I can see these options:

Let Packit act as a proxy user (Packit triggers action but the user is visualised and notified)

Similarly how Bodhi uses the Koji submitter for automatic Rawhide updates.
Could better show a real and responsible person instead of a bot.
What would be needed: looks like Koji can do this, I am not sure about Bodhi. We would also need to rethink Packit identity/authentication.

Add the possibility to specify people to notify when triggering actions

When submitting a build or creating an update, one can specify people to be notified.
What would be needed: This would probably need to be implemented in the services (we are interested in Koji and Bodhi).

Create a new message relay

Packit can listen to the messages and forward them to the relevant packager.
I don't like that this basically reinvents FMN.
What would be needed: New Packit-specific service.

Simplify/automate FMN rule creation

Find a way how to increase the chance that a user configures the notification -- e.g.:
- provide URL with prefilled details of the rule (login and confirm is the only action needed)
- create this rule for the user automatically
- Set up the rule for the user automatically as a reaction to an explicit action by the user, e.g. :thumbs-up: to the Packit comment)
What would be needed: depends on the solution

I would rather avoid version 3 and am worried version 1 could take too much work.

Does anyone have any other ideas? Am I missing something more straightforward? I hope if we agree on the way forward we can move on to the specific tasks...

Thanks @kevin for the reminder. I hope we've improved the situation for Packit users to suggest and document how to configure notifications: https://packit.dev/docs/fedora-releases-guide/fedora-notifications This works quite well and I like that this is not a Packit-specific feature so everyone can do the same. (I.e. people being notified about activities of co-maintainers) But I still worry this is not ideal since it's not done by default. So, I can see these options: 1. Let Packit act as a proxy user (Packit triggers action but the user is visualised and notified) * Similarly how Bodhi uses the Koji submitter for automatic Rawhide updates. * Could better show a real and responsible person instead of a bot. * What would be needed: looks like Koji can do this, I am not sure about Bodhi. We would also need to rethink Packit identity/authentication. 2. Add the possibility to specify people to notify when triggering actions * When submitting a build or creating an update, one can specify people to be notified. * What would be needed: This would probably need to be implemented in the services (we are interested in Koji and Bodhi). 3. Create a new message relay * Packit can listen to the messages and forward them to the relevant packager. * I don't like that this basically reinvents FMN. * What would be needed: New Packit-specific service. 4. Simplify/automate FMN rule creation * Find a way how to increase the chance that a user configures the notification -- e.g.: * provide URL with prefilled details of the rule (login and confirm is the only action needed) * create this rule for the user automatically * Set up the rule for the user automatically as a reaction to an explicit action by the user, e.g. :thumbs-up: to the Packit comment) * What would be needed: depends on the solution I would rather avoid version 3 and am worried version 1 could take too much work. Does anyone have any other ideas? Am I missing something more straightforward? I hope if we agree on the way forward we can move on to the specific tasks...

kevin commented

2025-12-11 17:46:34 +00:00

Owner

Hey, sorry this dropped off the radar. ;(

I personally think option 4 is best, but then which suboption I have no idea.

@abompard can you chime in from a FMN implementation standpoint? Is there any way to do those things?

Hey, sorry this dropped off the radar. ;( I personally think option 4 is best, but then which suboption I have no idea. @abompard can you chime in from a FMN implementation standpoint? Is there any way to do those things?

abompard commented

2025-12-19 13:42:20 +00:00

Member

Yeah I think option 4 would be doable, we could provide a way to build a URL that people could click on to add the rule. I just need to think of a way to avoid duplicates (even though multiple matching rules only generate one notification per incoming message).

zlopez commented

2026-03-26 17:43:16 +00:00

Owner

I'm adding my vote for option 4.

Somebody just needs time to implement this.

I'm adding my vote for option 4. Somebody just needs time to implement this.

lbarczio commented

2026-04-02 12:42:18 +00:00

Hi! Thanks all for providing feedback here so far. This topic was brought up again recently by Packit users so it would be great if we could prepare some actions items here. I think the conclusion seems to be the option 4.

@abompard, you're suggesting sub-option 4a, correct? That would still require Packit to notify users and then for users to click through, log in, and confirm. The other sub-options (4b/4c - automatic rule creation) would achieve better results from a UX perspective, but Packit would need to be able to create FMN rules on behalf of users via API. Do you think that's something FMN could support? Or is 4a the only feasible path?

Hi! Thanks all for providing feedback here so far. This topic was brought up again recently by Packit users so it would be great if we could prepare some actions items here. I think the conclusion seems to be the option 4. @abompard, you're suggesting sub-option 4a, correct? That would still require Packit to notify users and then for users to click through, log in, and confirm. The other sub-options (4b/4c - automatic rule creation) would achieve better results from a UX perspective, but Packit would need to be able to create FMN rules on behalf of users via API. Do you think that's something FMN could support? Or is 4a the only feasible path?

kevin commented

2026-07-09 17:32:35 +00:00

Owner

So, this has sat for a while sadly. ;(

I guess next steps are code in FMN to do any of those option 4 things?

So, this has sat for a while sadly. ;( I guess next steps are code in FMN to do any of those option 4 things?

Rows
Columns

Reporting for other maintainers (~Packit users) #12234

Describe what you would like us to do:

When do you need this to be done by? (YYYY/MM/DD)