#7690 bugzilla sync fixing [meta]
Opened 3 months ago by kevin. Modified a month ago

There are currently 4 tickets open on our bugzilla sync script.

We should look at a short sprint to fix these and improve additional issues.

First, it's unclear if our script is actually even working. I see in debug it was trying, but it never changed owners here, I did it manually:


We used to reassign bugs on point of contact change, but this was lost, we should do so again:


The current script is not very robust:


Additionally, it was broken by a bad commit to fedora-scm-requests repo, fixed in https://pagure.io/releng/fedora-scm-requests/c/4443201c62dd8ce55679abeb1e9346fb3a860095?branch=master

We don't currently, but we should close retired packages to new bugs:

Additionally we currently run this script as a cron, perhaps it could be fedora-messaging triggered and targeted for only things it needs to change and run in cron once a week to pick up anything it missed?

Also, we have a number of people who are cc/poc/whatever on items but have no bugzilla account. Currently we nag them, but it doesn't seem that effective. Perhaps we can think of some better way to enforce this?
Or just assign things to their @fedoraproject.org alias since openid will let them login as that?

@cverna and @pingou both expressed some interest in this.

What are our next steps? Meet up and scope out the work?

Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

3 months ago

@kevin I think we should schedule a week to work on this and from there work backward to build up the scope of the work and the goal for that week.
@cverna is off until next week Monday, should we schedule this for the week of May 20th? (I'm off on the 15th so if we take the week of May 12th, I'll have one day less to work on this, which is fine if we're better with that week).
From there we should start gathering the requirements next week to define exactly what the script should do, what are the inputs and the outputs and how to debug a situation.

Here is a summary of the requirements we have for the script based on our meeting from yesterday:

Bugzilla sync script

Tracker: https://pagure.io/fedora-infrastructure/issue/7690

So the principal of the script is to take poc and cc from dist-git and sync them
to bugzilla, it's a one way sync dist-git -> bugzilla.
If there is not a bugzilla account corresponding to the email set in FAS for
this user, orphan the package or remove the person from the watch list.
If a package is retired, the script will close bugzilla to new bugs (ie: no new
bugs will be open for this component).
If the script fails to retrieve from dist-git or FAS, it should retry a few times
before failing.
If the script fails to interact with bugzilla, it should retry a few times before
skipping that entry (ei: 1 wrong record is better than several ones)

The script should accept a configuration file containing:
- the overrides of the people not wanting to use in bugzilla the email they have
set in FAS
- a hard-coded list of: components, potentially: sub-components,
point of contact

The first list will replace the overrides we have currently hard-coded in the
script, The second list will allow to create components and potentially
sub-components with their corresponding point of contact, allowing to properly
manage spins and distributions in Fedora.

The script will use as input:
- a JSON file generated by a cron script on dist-git
- FAS to retrieve user and group information

In addition to this work on the script itself, two pieces of code will need to
be touched:
- pagure-dist-git
It will need to gain support for storing per product (Fedora, Fedora EPEL)
point of contact on the rpms namespace.
- the cron job
The cron job that generates the JSON file used by the sync script will need to
be adjusted to take in account the point of contact set per project in
pagure-dist-git above.
The cron job will also need to be adjusted to include retired packages.

Finally, the script should be able to run for a single project or all (which
would be the default). This would allow to trigger it via fedora-messaging and

Unanswered question:
- Should pagure-dist-git only accept FAS username or can it also accept email
addresses? This would allow to make a bugzilla account not corresponding to a
FAS account point of contact on certain components.

Should pagure-dist-git only accept FAS username or can it also accept email

See https://pagure.io/fedora-infrastructure/issue/7755 - e-mail addresses would be great.

See https://pagure.io/fedora-infrastructure/issue/7755 - e-mail addresses would be great.

It would be handy but may have some security implications as well as opening a door to some sort of DOS on users (I'm quite sure you don't want to me made POC for all of the kernel bugs :))

I don't want to be made POC for all kernel bugs by my e-mail address nor by my FAS account. I think I miss the difference here?

I don't want to be made POC for all kernel bugs by my e-mail address nor by my FAS account. I think I miss the difference here?

There are more bugzilla accounts than FAS ones, so it does restrict a little bit the set of options, with FAS account we can do some checks (group membership for example), but you may be right and maybe the difference isn't that big.

I see. From the user POV, I'm fine if I have to whitelist / confirm the e-mail address via a manual action.

Another item to add: https://pagure.io/releng/issue/7393 (no perl component in modules, but we have a perl module)

Login to comment on this ticket.