Re: fedora messaging
On 08/16/2018 11:53 AM, Michal Novotny wrote:
On Thu, Aug 16, 2018 at 11:43 AM Jeremy Cline
<jeremy(a)jcline.org> wrote:
<snip>
> The current solution is fedmsg-meta-fedora-infrastructure, a
central
> Python module where schema are poorly encoded by a series of if/else
> statements. It also regularly breaks when message schema change. For
> example, I have 2200 emails from the notifications system about how some
> Copr and Bodhi messages are unparsable. No one remembers to update the
> package, and it ultimately means their messages are dropped or arrive to
> users as incomprehensible JSON.
>
Yup, on behalf of Copr, I am sorry for that. This was caused by some bugs in
our code. But these things would be captured by the publisher validation in
the new framework. By the way, we would also like to have validators like
"NEVRA" available, maybe in a library, maybe we can implement it ourselves.
In one of the instances, we weren't sending release (I think) and it broke
the
fedmsg-meta service. That service is kind of sensitive.
Yes, it is sensitive. And to be clear, I'm not pointing fingers here.
It's just a good example of how what we're doing now doesn't work. I
want to put the ability (and responsibility) to making a message
readable and documented in the hands of app maintainers.
>
> With the current approach, you can just implement a __str__ method on a
> class you keep in the same Git repo you use for your project. You can
> write documentation on the classes so users can see what messages your
> projects send. You can release it whenever you see fit, not when whoever
> maintains fedmsg-meta has time to make a release.
>
> It seems like your main objection is the Python package. Personally, I
> think making a Python package is a trivial amount of work for the
> benefit of being able to define an arbitrary Python API to work with
> your messages, but maybe that's not a widely-shared sentiment. If it's
> not and we decide the only thing we really want in addition to the
> message is a human-readable string, maybe we could include that in the
> message in a standard way.
Might be also a way.
So, am I right in saying your main objection is the Python package? Or
do you object to then packaging that as an RPM?
--
Jeremy Cline
XMPP: jeremy(a)jcline.org
IRC: jcline