15:06:07 <mizmo> #startmeeting hubs-devel
15:06:07 <zodbot> Meeting started Tue Apr 18 15:06:07 2017 UTC.  The chair is mizmo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:07 <zodbot> The meeting name has been set to 'hubs-devel'
15:06:16 <mizmo> its all  good jcline
15:06:19 <mizmo> is sayan out today maybe
15:06:29 <abompard> maybe
15:06:33 <mizmo> let's do a status anyway
15:06:40 <abompard> +1
15:06:45 <abompard> .hello abompard
15:06:47 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
15:06:57 <mizmo> abompard: how are you doing? you were working on FAS auth and the feed widget, right?
15:08:54 <abompard> mizmo: I have pushed that PR already
15:09:01 <abompard> sayan has started reviewing it
15:09:07 <abompard> but wants to test it some more locally
15:09:09 <mizmo> for fas auth?
15:09:15 <abompard> yes
15:09:29 <abompard> it's a first version that does not get the groups from FAS
15:09:45 <mizmo> awesome
15:09:51 <mizmo> lemme note it -
15:09:52 <abompard> it uses the internal Hubs groups
15:10:06 <mizmo> #info abompard pushed PR for 1st cut FAS auth that uses internal hubs groups instead of FAS groups
15:10:15 <mizmo> #action sayan to finish reviewing / locally testing abompard FAS auth PR
15:10:15 <abompard> but to get the groups from FAS we'll need Patrick's new API (CAIAPI)
15:10:37 <abompard> Now I'm working on the Feed widget
15:10:37 <mizmo> is that a longer term thing?
15:11:20 <abompard> well yeah, because having hubs get the groups from FAS is one thing, having it *change* the membership in FAS is another
15:11:47 <abompard> so I hope we can have the getting part before Flock, I'm not sure about the setting part
15:12:02 <mizmo> okay cool -
15:12:11 <abompard> but with the PR, at least devs can start protecting their methors
15:12:13 <abompard> methods*
15:12:16 <mizmo> #info goal for Flock is to have FAS group getting from FAS (group seting is post-flock)
15:12:18 <abompard> and view
15:13:10 <abompard> I don't think it will matter much for a demo at Flock anyway
15:13:27 <abompard> so if there are more urgent priorities, it can be arranged
15:13:28 <mizmo> yeh i think auth alone is fine for flock
15:13:35 <abompard> yeah
15:13:46 <mizmo> #info FAS group getting/viewing for flock is low priority
15:14:02 <mizmo> how is the feed widget going?
15:14:13 <abompard> not as good as I had hoped :)
15:14:30 <abompard> There's a part of the backend that's apparently missing
15:14:48 <abompard> the part that would get the feed content from FMN
15:15:06 <abompard> and the part that would allow auto-update (SSE)
15:15:36 <abompard> So I've talked to jcline about that, we may have to plug something into FMN to get the data
15:15:50 <abompard> but that's still being discussed with pingou too on a GitHub ticket
15:16:11 <jcline> Yeah, I filed an issue https://github.com/fedora-infra/fmn/issues/178
15:16:34 <abompard> So I'm working on the Feed widget itself because there are still that can be improved in the way it's setup
15:16:49 <jcline> Then there's some additional stuff so FMN knows about groups and they can have their own filters
15:16:53 <abompard> especially on the "streams" page
15:17:05 <abompard> jcline: yeah, that too.
15:17:17 <jcline> (https://github.com/fedora-infra/fmn/issues/179)
15:18:04 <mizmo> so what is the difference between these issues and how the feed widget was working last summer? (at a high level)
15:18:12 <mizmo> (just so i understand better)
15:19:54 <abompard> I haven't really looked at it last summer. From the docs I can only suppose it was getting information from a local datanommer instance, which is not what we can use in prod.
15:20:16 <abompard> but maybe someone with a longer history with the hubs code will have more info?
15:20:40 <jcline> mizmo, when you say last summer do you mean the SSE work?
15:21:15 <mizmo> jcline: yeh, at the end of his internship atelic had a working feed widget that live updated and i think it was part of the SSE work, but it did seem like a raw-ish dump of fedmsg stuff without any filtering
15:21:35 <mizmo> ah ok we can't use datanommer in prod?
15:21:46 <jcline> Oh hmm
15:22:36 <jcline> So what abompard proposed is that we add a fedmsg backend to FMN (so messages can be filtered) that the hubs server would listen to and cache as appropriate
15:23:09 <mizmo> so, is this right -
15:23:21 <mizmo> fedmsg (raw stuff) => FMN => fedmsg (copies of the raw stuff now filtered) ?
15:23:37 <abompard> mizmo: yep!
15:24:14 <mizmo> and how does this compare to how SSE works?
15:25:29 <abompard> mizmo: we'll need something that will listen to fedmsg (the filtered part) and generate data in the SSE protocol
15:26:20 <mizmo> so the difference here maybe is that atelic had SSE hooked up to datanommer for filtering, and since that's not something we can do in prod, instead you're going to hook SSE up to a fedmsg feed that comes out of FMN?
15:27:00 <abompard> yeah
15:27:04 <abompard> (what I mean by "we can't use datanommer in prod" is more "we can't have a second instance of datanommer in prod", plus it would not allow filtering anyway)
15:28:01 <mizmo> ah ok
15:28:03 <abompard> I may be mistaken but it would seem very strange to have a second instance of datanommer only for hubs.
15:28:14 <mizmo> can we not use the datanommer that's already deployed?
15:28:20 <jcline> Yeah, I agree. Plus it'd be unfiltered.
15:28:35 <abompard> yeah there's the filtering issue
15:29:17 <mizmo> ah i thought datanommer allowed for filtering
15:29:30 <jcline> Also abompard, just so I'm clear, the full proposal is fedmsg (raw stuff) => FMN => fedmsg (filtered) => hubs server => hubs client (via some API?)
15:29:38 <mizmo> data nommer = eating/processing data? (nom-nom?)
15:29:48 <abompard> mizmo: yeah :)
15:30:06 <abompard> jcline: yeah, the hubs server => hubs client would be where SSE is used
15:30:40 <abompard> so what we need to write is a fedmsg to SSE gateway, pretty similar to your existing fmn.sse code
15:31:00 <jcline> Oh. But it'll be cached on the hubs server?
15:31:29 <abompard> jcline: yeah, so there's going to actually be 2 fedmsg listener on the hubs server
15:31:58 <abompard> jcline: the fmn.sse lookalike that does no caching, and one inside the flask code that can't do SSE
15:32:47 <abompard> jcline: Or, we can have the fmn.sse lookalike update the cache itself, but that seems... icky from an architecture point of view
15:33:44 <jcline> Hmm. I need to think about this a bit.
15:33:59 <abompard> but maybe not, I need to think about this too
15:34:10 <abompard> after all the cache address is already in the fedmsg config
15:35:26 <abompard> anyway it's not much of a difference because hubs already listens to fedmsg
15:36:07 <abompard> jcline: let's discuss this after the meeting :)
15:36:12 <jcline> Yeah
15:38:12 <mizmo> cool
15:38:25 <mizmo> any other status to report? what have you been up to jcline? iirc trying to get matrix deployed?
15:39:16 <jcline> The synapse package is still in need of a review, I've just been buried in other work (I've been helping out with bodhi a lot lately)
15:39:47 <jcline> I need to poke someone about reviewing it, or do a review trade or something.
15:41:09 <mizmo> #action need to find someone to review synapse package for jcline
15:42:20 <mizmo> its python? so better to find someone who has experience reviewing python stuff?
15:43:26 <jcline> Yeah, it's Python
15:43:36 <jcline> Maybe I can cash in a favor with bowlofeggs
15:44:03 <mizmo> hehe
15:44:06 <mizmo> okay!
15:44:09 <mizmo> anything else to discuss today?
15:44:36 <jcline> I don't have anything else
15:45:04 <mizmo> okay cool
15:45:07 <mizmo> i'll end meeting then :)
15:45:09 <mizmo> #endmeeting