13:34:27 <ianweller> #startmeeting fedmsg talk (ralphbean)
13:34:27 <zodbot> Meeting started Fri Aug  9 13:34:27 2013 UTC.  The chair is ianweller. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:34:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:34:33 * ianweller repastes everything he's said
13:34:40 <ianweller> 14:03 < ianweller> you can watch fedmsg in #fedora-fedmsg
13:34:40 <ianweller> 14:03 < ianweller> fedmsg is a messaging bus that allows various fedora applications to talk to each other
13:34:43 <ianweller> 14:04 < ianweller> the idea was to ease the process of developing and maintaining infrastructure
13:34:46 <ianweller> 14:04 < ianweller> there's not necessarily the kind of cohesion there could be yet, right now it requires expert knolwedge at each piece of the puzzle
13:34:49 <ianweller> 14:04 < ianweller> he has a "technical diagram" which is a photo of a rube goldberg machine
13:34:52 <ianweller> it uses x.509 certs to sign messages, similar to HTTPS certs.
13:34:57 <ianweller> helps with open infrastructure
13:35:10 <ianweller> everybody can read, everybody can write, but only fedora's infra can sign messages as trusted
13:35:23 <ianweller> fedmsg is buit on top of zeromq (written ØMQ)
13:35:37 <ianweller> as far as we know, there is no central broker, no SPOF
13:36:02 <ianweller> actual technical diagram follows. this diagram shows all of the fedmsg components integrated into all the components of fedora's infrastructure.
13:36:32 <ianweller> fedmsg is publicly subscrible
13:36:39 <ianweller> tcp://hub.fedoraproject.org:9940 with zmq.SUB socket
13:36:51 <ianweller> has fedora in the name but debian has started using it too
13:37:00 <ianweller> so now fedmsg is the "federated message bus"
13:37:21 <ianweller> debian is also making progress with fedmsg
13:37:26 <ianweller> #topic how to do it
13:37:31 <ianweller> sudo yum install fedmsg
13:37:41 <ianweller> the rest of these are shell lines, which are on his slides (trying to find url)
13:37:49 <ianweller> fedmsg-logger takes content from stdin and shoves it into the bus
13:39:09 <ianweller> on the consuming side, you can use fedmsg-tail (recommend using --really-pretty)
13:41:07 <ianweller> consuming messages is as easy as extending fedmsg.consumer.FedmsgConsumer
13:41:31 <ianweller> there is a system called fedmsg.meta which is plugin-based
13:41:53 <ianweller> you can install the fedora infra plugin, and it knows how to turn our JSON messages for fedora infrastructure into humanspeak
13:42:37 <ianweller> fedmsg has an option to use the fedmsg.meta plugins
13:42:51 <ianweller> there is also a --gource option, and it prints out fake git histories, which you can pipe to gource
13:43:06 <ianweller> threebean is demoing a gource video sourced from fedmsg now
13:43:43 <ianweller> #topic topics
13:43:53 <ianweller> full list at fedmsg.com/en/latest/topics
13:44:15 <ianweller> most popular topics is stuff like "askbot.post.edit", "git.receive", "wiki.article.edit"
13:44:44 <ianweller> next steps are bugzilla (problems) and mailman (almost done)
13:45:48 <ianweller> dwa's koji stalk monitors.. missed the rest of the slide
13:46:11 <ianweller> FAS2Trac (fama updater) listens to messages on the bus that users have applied to ambassadors, and it files a ticket in trac for it
13:46:35 <ianweller> not running on fedora infra, but running herlo's machine
13:46:53 <ianweller> p3ck's fedmsg-download listens for messages for the daily branches of rawhid ecompose messages
13:47:04 <ianweller> lmacken's fedmsg-notify listens for messages you care about and pops them up with libnotify
13:47:46 <ianweller> turn on / off categories and also filter by users, packages, etc
13:48:31 <ianweller> busmon is threebean's application that runs in a web browser with a websocket
13:48:36 <ianweller> shows messages live and graphs them over time
13:49:04 <ianweller> datanommer noms the data, every message that comes in goes into the postgres database
13:49:15 <ianweller> datagrepper allows public queries on the database via a JSON HTTP API
13:49:39 <ianweller> pingou has been busy writing tools that hit datagrepper...
13:49:51 <ianweller> first of is fedora news, makes queries to datagrepper to get latest stuff happening in fedora
13:50:20 <ianweller> this-week-in-fedora is a cronjob that runs weekly and scrapes through all the information in the last week, and publishes statistics in the top areas of activity
13:50:25 <ianweller> pretty graphs!
13:50:54 <ianweller> owner changes report tool, which reports package owner changes and sends them to devel list
13:51:44 <ianweller> also fedora-badges (launching this weekend, talk tomorrow)
13:51:51 <ianweller> uses fedmsg as the data backend.
13:52:04 <ianweller> fedmsg and datanommer if i recall correctly
13:52:23 <ianweller> #topic future stuff
13:52:48 <ianweller> debian deployment -- you can listen to it by adding tcp://fedmsg.olasd.eu:9940 to your /etc/fedmsg.d/endpoints
13:52:54 <ianweller> code is on threebean's slides
13:53:16 <ianweller> debian developers have contributed for the 0.7.0 release
13:53:26 <ianweller> persistence and replay, gpg signatures, and DNS discovery via SRV records
13:54:53 <ianweller> debian's infra is more spread out than fedora and nodes/services end up going out, so they want servers to be able to request replays of the last few minutes
13:55:10 <ianweller> it's added as a plugin, so we won't be using it in fedora
13:55:34 <ianweller> (it's essentially a distributed datastore as opposed to datanommer)
13:55:48 <ianweller> we do message signing with X.509, they wanted GPG, so fedmsg does both :)
13:56:27 <ianweller> fedora can manage fedmsg configurations using puppet/ansible, but debian didn't have that, so they are doing configuration via DNS SRV records.
13:56:46 <ianweller> fedora mobile, relrod's android app, has push notifications from fedmsg
13:57:10 <relrod> ;D
13:57:56 <ianweller> fedmsg-notifications: all of our current applications send their own emails right now
13:58:04 <ianweller> we had a problem with askbot upgrade in production not sending emails and it took a week
13:58:10 <ianweller> git has a hook to send email
13:58:15 <ianweller> we have no idea if it stops working unless someone tells us
13:58:25 <ianweller> and sometimes people don't want those emails
13:58:46 <ianweller> a centralized notification system where users can manage their email preferences for all systems and emails can be fired off by fedmsg is much much nicer
13:59:03 <ianweller> and then we don't have to worry about maintaining email code when we upgrade stuff.
13:59:19 <ianweller> in the future, we could end up letting people choose between email or android push or private IRC notifications(!)
13:59:43 <ianweller> there's a repo on github but it just has notes
14:00:15 <ianweller> notes/design document/words
14:00:27 <ianweller> mirrors poll with rsync right now
14:00:44 <ianweller> we want to be able to tell mirrors when we update via fedmsg instead of having mirrors poll all the time
14:01:15 <ianweller> fedmsg-trigger is a tool that can do that :o
14:01:22 <ianweller> (man i gotta do that on my private mirror at home)
14:01:41 <ianweller> so you can use fedmsg-trigger to execute a shell script when the compose message gets fired out.
14:01:52 <ianweller> that's coming in 0.7.0.
14:01:57 <ianweller> slides are done. Q&A from IRC?
14:02:14 <ianweller> http://threebean.org/presentations/fedmsg-flock13/ are the slides
14:02:47 <ianweller> question: how much reliability is there in fedmsg and is it something we can rely on for critical infrastructure? it's fire-and-forget, is the network reliable enough to assume everything will be received
14:03:16 <ianweller> answer: we need to decide collectively, threebean's opinion is that there's no guarantee of message state because then you have to have distributed state, but it's a safe assumption that messages will get there
14:03:40 <ianweller> we had some problems previously but since updating to 0mq 3, no reports of dropped messages since january
14:04:05 <ianweller> question (same person): how do you reconcile that if a message gets dropped and now there are builds missing on s390, ppc, because something happened?
14:05:22 <ianweller> my answer was datagrepper and some other stuff and for some reason i can't transcribe me speaking
14:05:42 <ianweller> question: why aren't we using the stuff debian is using for reliability
14:05:50 <ianweller> answer: adds a lot of weight with databases in our infrastructure and can lock applications
14:06:04 <ianweller> we may be able to do it for critical systems
14:06:30 <ianweller> question: (couldn't hear)
14:06:49 <ianweller> answer: our infrastructure checks that the message is signed by our certificate authority, and then checks that the message topics are coming from the right servers.
14:07:22 <ianweller> the first check is checked by everybody, including out-of-infrastructure clients
14:07:30 <ianweller> the second check is just in fedora infra but there's no reason we couldn't put it in a package
14:07:35 <ianweller> question: roadmap for future?
14:07:55 <ianweller> answer: revolutionary development is over now, it's relatively safe, it's now on getting new things into fedmsg (bugzilla, mailman, etc)
14:08:02 <ianweller> on the consuming side there's a lot of things we can do (autoQA, etc)
14:08:10 <ianweller> question: so you need more people to write tools/consumers?
14:08:13 <ianweller> answer: yes
14:08:23 <ianweller> question: tickets for new tools/consumers?
14:08:25 <ianweller> answer: yes :)
14:08:46 <number80> ;)
14:08:48 <ianweller> threebean will probably add a fedmsg-enablement component to the fedora infra trac on hosted
14:09:30 <ianweller> question: (couldn't hear)
14:09:47 <ianweller> answer: there is a plugin for mailman that just sends data to fedmsg
14:09:52 <ianweller> can just be copied to another plugin for another app
14:10:09 <ianweller> we could make it generic but it's not quite obvious to threebean that it /should /be
14:10:31 <ianweller> question: is it pubsub or what
14:10:45 <ianweller> answer: it is pubsub, the way it works is you receive all messages if you are on the external endpoint
14:10:53 <ianweller> but the technology is there to push your subscription to the server
14:11:00 <ianweller> but our volume of messages is low enough right now where that's not a problem
14:12:33 <ianweller> question: (long questoin that i'm not hearing half the words for because i'm in the middle of the room not the front)
14:13:03 <ianweller> discussion: we could eventually be linking distributions together on stuff like tracking security bugs
14:14:12 <ianweller> )(more discussion about cross-distro stuff that i can't quite hear
14:14:21 <ianweller> (i'm bad at parentheses)
14:15:27 <ianweller> #endmeeting