During the FESCo meeting on 2018-04-06, a question came up about whether it was a problem that people can submit buildroot overrides for packages that are not their own.
I noted that one potential risk might be someone inserting a buildroot override for an older GCC with a known vulnerability in code-generation. We discussed for a bit and considered that we probably don't want to restrict the buildroot overrides to owners just yet, but we should probably make sure that the package owners are always notified when such an event occurs so that they can react if it's possible that it will cause issues.
Koji sends fedmsg when build is tagged as override. Unfortunately FMN deliberately ignores these messages, so users can't be notified about them.
I don't know what the reason was for ignoring those messages, but I certainly don't have a problem adjusting the topic subscriptions to pick those messages up in FMN.
The reason is performance, see https://github.com/fedora-infra/fmn/issues/99
Ah. Well, FMN still has plenty of performance problems, but it uses Celery now so we can throw more workers at the problem. The real solution would be to use sensible message topics and the filter tools provided by a message queue library (be it ZMQ or AMQP), but that will take a lot of work. What's the specific topic Koji uses for builds tagged as overrides?
The topic is org.fedoraproject.prod.buildsys.tag. It is currently marked as "junk" in roles/notifs/backend/templates/fmn.consumer.py
Note that overrides are a subset/special case here.
buildsys.tag is emitted all the time as builds are tagged into various tags, it's a ton of traffic.
Overrides are only when a build is tagged into a override tag (f26-override, f27-override, etc)
So, if we could filter out this case it would be almost no traffic.
If the override got a specific topic it'd be super easy. Something like org.fedoraproject.prod.buildsys.tag.override.<pkg-name>.<dist-tag> would allow people to:
org.fedoraproject.prod.buildsys.tag.override.<pkg-name>.<dist-tag>
If you want all overrides for a dist you'd need to subscribe to org.fedoraproject.prod.buildsys.tag.override and filter further in code (or use other AMQP headers if we were in the AMQP world).
org.fedoraproject.prod.buildsys.tag.override
Of course, that would require a lot of changes in messaging infra so we can't have that right now. We could add a special hack to the long list of special hacks in the fmn frontend to do some filtering on top of the topic (although that's fragile because message schema change without announcements) if the number of tag messages is too high. Based on datagrepper it doesn't look that busy to me, though.
Actually I just noticed that Bodhi is supposed so emit specific fedmsg bodhi.buildroot_override.tag when override is requested. Users should be able to subscribe to them via FMN.
I also noticed I'm already getting notifications about buildroot overrides on packages I maintain:
Apr 05 22:56:52 <fedora-notif> ralph expired a buildroot override for python-datanommer-models-0.9.1-2.fc28 https://bodhi.fedoraproject.org/overrides/python-datanommer-models-0.9.1-2.fc28 Apr 05 22:57:14 <fedora-notif> ralph submitted a buildroot override for python-datanommer-models-0.9.1-3.fc28 https://bodhi.fedoraproject.org/overrides/python-datanommer-models-0.9.1-3.fc28 Apr 06 15:00:10 <fedora-notif> bowlofeggs expired a buildroot override for erlang-luerl-0.3-1.fc28 https://bodhi.fedoraproject.org/overrides/erlang-luerl-0.3-1.fc28
So, this is all already done then?
@sgallagh Is there any further thing we can do here?
Metadata Update from @kevin: - Issue priority set to: Waiting on Reporter
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)