#2017 protonmsg should send only basic info
Closed: Fixed by tkopecek. Opened by tkopecek.

Builds (especially from MBS) can have very large extra info. This data doesn't make much sense on message bus. There should be only basic build information. Remove that data from all protongmsg messages.


I suspect that a number of systems rely on receiving some of the extra fields. I'm not sure that cutting out extra entirely is the way to go.

I think MBS is abusing this field more than a bit.

Metadata Update from @mikem:
- Custom field Size adjusted to None

Yes, MBS puts modulemd content in the extra data(the same as the archive - modulemd.txt). I think it could be removed.
On the other hand, someones rely on this information in the extra data rather than the content in the archive.

BTW, it looks neither the extra data nor the archive file contains the whole modulemd.txt data. they end with "..."

@julian8628 ... means EOF in this case (if file starts with ---)
@mikem So, you want to do some change in MBS? Does it make sense to drop modulemd_str? It is faster to get it via API, then downloading the modulemd.txt, but it probably shouldn't be there. ...or ugly hack and drop it in protonmsg plugin.

@julian8628 ... means EOF in this case (if file starts with ---)

ah, ok :)

Regardless of anything else, MBS needs to stop cramming this gigantic text value into build.extra.

That said, we do need to take steps in Koji to both:

  1. deal with future tools that might similarly misbehave
  2. deal with existing data in the system

A few things come to mind:

  • a (configurable?) limit on the size of build.extra. Exceeding would cause the import to fail.
  • protonmsg plugin could follow the same limit and simply omit the build.extra field if it is too large. While this sort of variable behavior feels a little questionable to me, I think that always omitting it is going to cause more problems and always including is causing the problem at hand.

I don't think we want to get into the weeds of mangling build.extra data to make it fit.

I couldn't find an MBS issue for that first part, so I filed one:

https://pagure.io/fm-orchestrator/issue/1592

I've looked to db and maximal size of extra is about 172kB, while average (for non-null) is 810. What would be best limit? I'm thinking about 2kB which covers 96% of what we have. 4kb would cover 99,3%, but it looks to me as a quite big for sending over message bus.

PR #2047 - I've decided to put default as unlimited.

Metadata Update from @tkopecek:
- Issue untagged with: discussion
- Issue tagged with: testing-ready

Commit 6caa66f0 fixes this issue

Commit d1e055f1 fixes this issue

Followup PR: #2115

Metadata Update from @jcupova:
- Issue tagged with: testing-done

Commit df4e5eb8 fixes this issue

Commit f039220a relates to this ticket

Commit dd9c9297 relates to this ticket

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/2017

Please continue any further discussion there.

Metadata
Related Pull Requests