Hi,
As part of my GSoC project this week, I've done the following:
— Hacked up some -bugs-dist support in debmessenger[1].
— Thought up a preliminary implementation of a replay protocol for
fedmsg in case of dropped messages[2][3].
— Deployed fedmsg on mentors.debian.net (well, most of the work has
been accomplished by Nicolas Dandrimont, kudos for that BTW).
For the curious amongst the readers, you can listen to the chatter
by adding tcp://mentors.debian.net:300[0-4] to the list of
endpoints.
— Implemented service discovery through SRV records in fedmsg
(untested as of today)[4]
For next week, I plan to:
— Rewrite the replay mechanism as the more I think about the current
implementation the less I'm happy with it.
— Deploy a fedmsg gateway that will consume all debian-produced
messages and resend them on a single endpoint, much like [5].
— Work out the last kinks in my packaging (I know, I say that every
week, but try to deal with an overcommitted sponsor ;-) )
— Maybe, deploy an instance of debmessenger somewhere.
Have a nice week-end all!
Cheers,
Simon
[1] https://github.com/laarmen/debmessenger/commit/dde1454cf362f4f4755d6c9b2a72…
[2] https://lists.fedoraproject.org/pipermail/messaging-sig/2013-July/000008.ht…
[3] https://github.com/laarmen/fedmsg/tree/feature/replay
[4] https://github.com/laarmen/fedmsg/tree/feature/srv-records
[5] tcp://hub.fedoraproject.org:9940
Hi,
As some of you might know, I am the student working on adapting fedmsg
for Debian as part of Google Summer of Code program.
One of the requirements for fedmsg to be part of Debian infrastructure
is to be resilient in case a network link drops, as we have services
dispatched all over the world. Currently, if a client drops out, it has
no way of catching up on what happened when it was offline.
To solve this, I was thinking of the following: all the endpoints that
must be able to replay some messages should provide two URLs, say
tcp://foo.bar:3000 and tcp+pair://foo.bar:3001, the later listening in
for PAIR-type[1] connexions. The clients on the simple URL are like the
current clients, but the PAIR socket allow the other clients to request
the missing messages.
The query would come on the $prefix.replay.$topic topic (say,
org.fedoraproject.dev.replay.buildsys.build.state.change), and specify
the IDs to resend, or a time interval (for manual queries), and the
answer(s) would come on the same topic.
To be able to detect a missing message, the "i" field would have to be
topic-bound instead of being at the endpoint level.
Thoughts?
Cheers,
Simon
[1] https://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/patterns/pa…
