Fedmsg Emitting

[Martin Krizek]

Before we start sending fedmsgs we need to discuss a few things. We don't
have to find solutions to all these problems, just keep them in mind
when designing the solution we're going to start with:

1. How often do we send fedmsg
a) per-task
b) per-update
c) per-build

a) and b): we can list affected packages in a fedmsg.

I am not sure if there are any limits when it comes to fedmsg size.
Whether the infra folks would be more happy with less larger or more
smaller fedmsgs (or it doesn't matter).

I guess c) allows to easier filtering in FMN.

2. Who do we target: users, systems or both

The issue here is with tasks that repeatedly test one update. Currently we
check if there's a bodhi update comment with the same result already and
if so, we don't post the comment again. To do something like that with
fedmsgs we'd have to have a code running somewhere that would check
against its database whether an incoming result is a duplicate or not. The
question is where the code would run. Bodhi comes to mind since it
already has information about updates and so is good for tasks that
work with bodhi updates. However, there might be tasks that work with
something else, like composes. In this case we'd probably have the code
on taskotron systems.

So if we target systems we'd just send all results in fedmsgs and let the
systems consume them and do whatever they want to do with them (e.g.
bodhi can squash all the tasks relevant to specific update and notify
the maintainer of the package via fedmsg about the result). If we
target users, we'd have to have some logic to limit rate of fedmsgs
ourselves but that would mean hiding some of the results (although
duplicates) from the world.

So the question here is where to put the 'deduplication logic'.

Emitting all results is the simplest solution as a starting point.

Thoughts?

Thanks,
Martin