16:05:51 <threebean> #startmeeting Messaging_SIG
16:05:51 <zodbot> Meeting started Tue Mar 27 16:05:51 2012 UTC.  The chair is threebean. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:59 <threebean> there we go.  :)
16:06:05 <tflink> threebean: you may want to do meetingname as well
16:06:19 <threebean> #meetingname Messaging_SIG
16:06:19 <zodbot> The meeting name has been set to 'messaging_sig'
16:06:35 <threebean> #chair tflink
16:06:35 <zodbot> Current chairs: tflink threebean
16:06:37 <j_dulaney> And roll call
16:06:40 <threebean> #topic roll call
16:06:49 * tflink is present
16:07:01 <threebean> Who all's in here for the Messaging SIG meeting?  (perhaps obviously ;p)
16:07:04 * threebean is present
16:07:09 * j_dulaney waves
16:08:05 <threebean> allright, that's it for today. :)
16:08:09 * ianweller waves hi
16:08:17 <threebean> #topic forming an agenda
16:08:20 <abadger1999> hola
16:08:59 <threebean> I was hoping today to talk about 1) open questsions on design and plans 2) sending messages from existing services and 3) other projects depending on the message bus
16:09:06 <threebean> would anyone like to add anything?
16:09:18 <pingou> hoi
16:09:40 <tflink> the only other thing I'm curious about is any projected timeframes
16:10:09 <tflink> ie weeks, months, years - to get a better idea of when we'll be able to use the system
16:10:12 <threebean> tflink: let's take it up in #1.
16:10:18 * nirik is lurking.
16:10:19 <tflink> works for me
16:10:26 <threebean> any others?
16:11:04 <threebean> #topic open questions on design and plans
16:12:23 <threebean> tflink: So on projected times, I feel confident we can have the sending of messages from the majority of services done (long) before the calendar year is out
16:13:29 <threebean> tflink: the python library is in a usable state for sending messages, it's just a question now of tracking down all the places where emitting messages makes sense and putting them there.
16:13:44 <tflink> threebean: cool, I assume that there is going to be some work in a staging-ish env before rollout to production systems?
16:13:54 <threebean> Oh, yes. :)
16:14:24 <threebean> Last meeting we asked which services we should prioritize, but didn't come to any definite conclusions.  Tagger is done, but hasn't been pushed to staging yet.
16:15:29 <ianweller> i have a list of ones we should prioritize :)
16:15:59 <threebean> ianweller: :) from statistics++?
16:16:02 <ianweller> yeh
16:16:07 <ianweller> https://fedoraproject.org/wiki/User:Ianweller/statistics_plus_plus#Requirements_for_release
16:16:11 <ianweller> it's up for debate of course
16:16:20 * j_dulaney looks
16:16:58 <threebean> ianweller: I was going to take on pkgdb next, but I'll switch course.  I don't have a real preference for the order we take it up.
16:17:05 <j_dulaney> Add to that Kojhi and AutoQA
16:17:08 <ianweller> the reason i'm looking at those five is because they're all very different from each other
16:17:31 <ianweller> j_dulaney: sounds good, /me does so
16:18:28 <abadger1999> ianweller: No git commits?
16:18:32 <abadger1999> ;-)
16:18:36 <ianweller> shit
16:18:37 <ianweller> good idea
16:18:45 <threebean> any other questions?  this is bleeding (understandably) into the second topic.
16:19:36 <threebean> #topic Sending messages from existing services
16:19:53 * tflink is slow but ...
16:20:09 <threebean> tflink: go for it
16:20:19 <tflink> are there any expectations on when existing services/projects are using the messaging system?
16:20:55 * tflink is specifically wondering if there are expectations for AutoQA to start using messaging at a certain point in time
16:21:07 <tflink> or is that more up to the individual projects?
16:22:00 <threebean> I don't have a timeline for it, but I think we first need 1) the existing services to be emitting messages and 2) the bus needs to be demonstrated as reliable.
16:22:01 * j_dulaney wonders if we should state that it needs to be done by a certain point
16:23:47 <threebean> j_dulaney: that would be good, so the project doesn't wander off into a bog.
16:24:32 <ianweller> i have some milestones i'm working on in the statistics++ spec as well
16:24:37 <threebean> the statistics++ states 6 months to be operational.  That will depends on the rest of the bus functioning.  Does that sound good?
16:25:31 <j_dulaney> +1
16:26:06 * tflink isn't pushing for faster, just trying to understand
16:26:24 <ianweller> i feel like we can get it done in less than 6 months, but that's a good date to have
16:26:30 <ianweller> if it takes longer, it's time to start reviewing stuff :P
16:26:36 <threebean> :)
16:27:42 <threebean> j_dulaney: I'll write that into the fedmsg doc.
16:27:58 <j_dulaney> Roger
16:28:38 <threebean> ianweller: by next week, I'll try to have progress we can show off on one of the services from the statistics++ list, too.
16:28:46 <ianweller> threebean: :D
16:29:10 <threebean> #topic Other projects
16:29:41 <threebean> All I wanted do here was plug ianweller's statistics++ and busmon - http://github.com/ralphbean/busmon
16:30:03 <ianweller> fwiw, i'm writing out the spec because it's an assignment for my technical writing course :P
16:30:08 <ianweller> but it's been a good thing so far
16:30:18 <ianweller> get most of the planning done before i start coding is something i need to do anyway
16:30:26 <threebean> ianweller: agreed, it's helped anchor me already.
16:30:38 <j_dulaney> Something to poke into all this
16:30:51 <j_dulaney> How about an API to make testing easier?
16:31:18 <threebean> j_dulaney: How do you mean?
16:31:34 <j_dulaney> Ie, include the facility to tell listening services to put results in a test db rather than a production db
16:31:39 <j_dulaney> If that makes sense
16:32:36 <threebean> j_dulaney: Trying to restate -- Include an API to make testing of services that use the bus easier.
16:32:50 <threebean> Like writing fake-bus stubs/mocks?
16:32:57 <j_dulaney> Not exactly
16:33:54 <j_dulaney> Say you manually poke a message onto the bus that includes a piece of info telling the listening service to direct its output to where you want it
16:34:33 <j_dulaney> Normal messages would have a null in that field in the message and so the listening service would act as per normal
16:34:42 <j_dulaney> Really, it's a message format thing
16:35:08 <threebean> Adding a 'this-is-a-test' field?
16:35:18 <j_dulaney> Indeed
16:35:30 <threebean> j_dulaney: cool.  so i understand more, can you explain a use case?
16:35:35 <tflink> threebean: common stubs/mocks might be a good idea so that we're not all writing them - i doubt that it needs to be a requirement but something for all of us to keep in mind
16:35:53 <j_dulaney> That's true, too
16:36:13 <j_dulaney> threebean:  I'm thinking, for instance, say for AutoQA
16:36:26 <j_dulaney> We want to test a new version
16:37:23 <j_dulaney> We manually (or batch) inject messages on the bus that should cause AutoQA to do specific things as a test
16:38:15 <tflink> j_dulaney: wouldn't that be better done with an isolated "test instance" (for lack of a better term coming to mind ATM)?
16:38:31 <j_dulaney> We include in the messages instructions to AutoQA to dump the results in a special DB OR output back to the message bus  messages that are clearly marked as test, to be ignored by production DBs
16:38:58 <threebean> Hmm.
16:39:04 <tflink> j_dulaney: I'd rather keep new AutoQA versions off production until they're ready, personally
16:39:19 <abadger1999> Rather than instructions, I think I'd rather mark the messages as being of a "testing" type
16:39:25 <threebean> Would it make more sense to alter the topic namespace to correspond with FI's different environments?  production, staging?
16:39:36 <abadger1999> the application would choose how to treat those differently
16:39:36 <j_dulaney> tflink:  I'm thinking that there could be a way to use this so that staging is tied into the bus and its results are ignored.  That way, full work load without the potential for bad results
16:40:00 <j_dulaney> threebean:  Indeed
16:40:05 <abadger1999> We'd probably also want the API to automatically filter out testing type messages by default.
16:40:12 <j_dulaney> +1
16:40:28 <abadger1999> but I'm not sure if, at that level, we're dealing with a fedmsg API or raw zmq API.
16:40:32 <threebean> messages from tagger right now are emitted on the 'org.fedoraproject.tagger.*', this could instead be 'org.fedoraproject.production.tagger.*' and 'org.fedoraproject.staging.tagger.*'
16:40:50 <j_dulaney> I was using AutoQA as an example, anything we have staging would apply
16:40:58 <threebean> agreed.
16:41:30 <abadger1999> If staging hits production's message bus...
16:41:33 <abadger1999> might not be good.
16:41:48 <threebean> abadger1999: fedmsg already does some guessing for you; it guesses it's calling module's name (in the above case, "tagger").
16:41:48 <abadger1999> Things like Fedora release freezes affect production but not staging
16:42:04 <j_dulaney> Hmm
16:42:19 <abadger1999> If we become tied to the message bus in production, things in staging that affect it would probably also need to be frozen during release.
16:42:22 <threebean> we could enhance that to 'guess' the production/staging environment name for you (or extract it from a config file).
16:42:25 <abadger1999> Which would get in the way
16:42:35 <j_dulaney> At the least, it would be good to have staging listen on the main bus
16:42:51 <j_dulaney> That way, you have testing with full, real world data
16:43:08 <abadger1999> j_dulaney: Might be good -- might also be bad
16:43:19 <abadger1999> if that's configurable, it might work out.
16:43:29 <abadger1999> (The bad is -- we don't have resources for a full staging env
16:43:30 <threebean> j_dulaney: *could* have.  I think we should isolate them by default.  The user should have to work hard to listen to the production bus from staging.
16:44:11 <abadger1999> So, for instance, a message from production koji that stg bodhi sees, might end up with stg bodhi needing to touch a stg koji server... which we wouldn't have)
16:44:32 <abadger1999> Also -- stg is potentially less secure than production.
16:44:54 <j_dulaney> If we can do it right, and isolate the correct bits, then it should be fine
16:45:08 <j_dulaney> Sorry, Internet blinked out
16:45:12 <abadger1999> so having stg listen on the production message bus could have ramifications as we move towards a future where some more sensitive data is on the bus.
16:45:34 <threebean> abadger1999: is there any firewalling between production and stg?
16:46:08 <j_dulaney> abadger1999:  how difficult would it be to have staging ignore sensitive stuff?
16:46:12 <abadger1999> threebean: I think that right now we firewall stg so that it can't talk to production at all (except for commmunity++ which was a frankenstein)
16:46:58 <abadger1999> j_dulaney: That road is "special case code to handle multiple environments" -- just feels like we're trying to solve it at the wrong level then.
16:47:05 <j_dulaney> Anyway, I'm trying to think of ways were we could use this to achieve better testing
16:47:22 <j_dulaney> abadger1999:  True
16:47:32 <abadger1999> Might be better to think about ways we could record and replay messages in a different environment.
16:48:03 <abadger1999> Seems... potentially resource intense, though.
16:48:22 <threebean> that would be quite nice.
16:48:28 <j_dulaney> That's why I was thinking that the thing would be to listen to the main bus
16:48:48 <abadger1999> <nod>
16:49:08 <j_dulaney> The idea being to hit staging with a full production incoming load without the expense of trying to simulate that load
16:50:12 <threebean> We're coming up on the hour-mark.  Are there any other topics that need to be taken up before we close?
16:51:41 <threebean> abadger1999: I'll add the FI environment as a mandatory field for topics in fedmsg.
16:52:10 <tflink> threebean: FI?
16:52:18 <threebean> tflink: Fedora Infra
16:52:33 <abadger1999> threebean: okay -- If we continue to firewall production from stg, we could just leave that out.
16:52:37 <tflink> ok, that's what I suspected but wanted to be sure
16:52:39 <threebean> The firewall between environments provides much more real protection, yes..
16:52:54 <threebean> abadger1999: mostly for readability.
16:53:00 <threebean> so we can look at messages and know where they're coming from.
16:53:06 <abadger1999> threebean: I'm just thinking that stg and production talking to each other is likely a bad system architecture.
16:53:38 <j_dulaney> abadger1999:  What's wrong with staging listening to production?
16:53:41 <abadger1999> k
16:53:47 <threebean> abadger1999: I agree.  The topic adjustment would provide only an extra superficial separation.
16:54:20 * nirik was doing other things, but I don't think we want stg having any connection to prod.
16:54:38 <abadger1999> j_dulaney: the things I mentioned about stg being less secure by design and then being able to access data in the production bus.
16:55:02 <j_dulaney> True
16:55:10 <abadger1999> j_dulaney: and stg not being a complete replica in terms of provided services from production
16:55:36 <threebean> j_dulaney: for testing, a more controllable record-and-replay approach is possible as a work around.
16:55:48 <j_dulaney> Indeed
16:56:15 <j_dulaney> Anyway,
16:56:20 <threebean> :)
16:56:21 <j_dulaney> 'twas and Idea I had
16:56:29 <j_dulaney> Thought I'd through it out
16:56:57 <threebean> j_dulaney: no, it's cool stuff.
16:57:14 <threebean> I'd hadn't thought yet at all about how we would test services making use of the bus.
16:57:31 * j_dulaney will think on this some more
16:57:47 <threebean> j_dulaney: please, and don't hesitate to contact me outside of meetings.  #fedora-apps is usually best.
16:58:04 <threebean> Any other last things before we close the meeting up?
16:58:35 <threebean> That's a wrap.  Thanks everyone!
16:58:37 <j_dulaney> threebean:  rgr
16:58:43 <threebean> #endmeeting