15:00:17 <langdon> #startmeeting modularity_wg
15:00:17 <zodbot> Meeting started Tue Jun 14 15:00:17 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:17 <zodbot> The meeting name has been set to 'modularity_wg'
15:00:28 <langdon> #meetingname Weekly meeting of Modularity WG
15:00:28 <zodbot> The meeting name has been set to 'weekly_meeting_of_modularity_wg'
15:00:34 <contyk> .hello psabata
15:00:35 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:40 <langdon> jkurik, ^^ will that mess up the logs?
15:00:50 <langdon> jkurik, meetingname i mean?
15:01:00 <langdon> or any other zodbot experts
15:01:04 <jkurik> langdon: I do not think so
15:01:07 <langdon> #chairs: dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink, threebean
15:01:08 <langdon> cool
15:01:16 <langdon> #topic Roll Call
15:01:18 <tflink> .hello tflink
15:01:18 <jkurik> .hello jkurik
15:01:19 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:01:21 <langdon> .hello langdon
15:01:22 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:01:25 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:45 <langdon> #topic Agenda
15:03:13 <langdon> #info Elections to Modularity WG
15:03:13 <langdon> #info demos sprint 7
15:03:13 <langdon> #info sprint 8 theme
15:03:14 <langdon> #info orchestrator
15:03:26 <langdon> ok.. let's get started?
15:03:36 <langdon> unless anyone has an agenda item to add/propose?
15:03:52 * lkocman is here
15:04:04 * threebean too :)
15:04:19 <sct> .hello sct
15:04:20 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:04:37 <langdon> ok.. let's start with elections
15:04:45 <langdon> #topic Elections to Modularity WG
15:04:52 <langdon> jkurik, i assume you are the lead for this?
15:04:58 <jkurik> #info Fedora Elections after F24 GA release are planned in period from 2016-June-27 to 2016-July-26
15:05:07 <jkurik> #link https://fedorapeople.org/groups/schedule/f-24/f-24-elections.html
15:05:18 <jkurik> #undo
15:05:25 <jkurik> #link https://fedorapeople.org/groups/schedule/f-24/f-24-elections.html
15:05:34 <langdon> ooo that is soon
15:05:52 * langdon wonders if his council seat is up for re-election
15:06:13 <jkurik> As there will be elections after F24 GA, I would ike to have a common concensus, whether we are going to re-elect the Wg members for Modularity WG
15:06:22 * lkocman finds himself confused about seeing Modularity WG elections and then f-24-elections next to each other
15:06:34 <contyk> me too :)
15:06:34 <jkurik> I expect no, but just to be sure ...
15:06:36 <langdon> lkocman, the cycle is for "any" election
15:06:41 <langdon> like we do them all at once
15:06:43 <lkocman> langdon: okay
15:07:20 <langdon> i would actually propose we do them... 1) to fit the normal schedule 2) the last ones were a bit wonky 3) revisit if people want to be "voting members"
15:07:27 <langdon> but.. i don't know how much work it is
15:07:36 <jkurik> IMO this WG is quite fresh and do need to be re-elected
15:07:50 <langdon> jkurik, "do" or "do not"?
15:08:03 <jkurik> ah, "do not"
15:08:05 <jkurik> sorry
15:08:14 <langdon> jkurik, figured based on earlier remark ;)
15:08:26 <jkurik> langdon: thanks :)
15:08:29 <langdon> jkurik, any rough estimate of effort you can providE?
15:08:45 <langdon> like for us or others?
15:08:58 <jkurik> for the WG there is not much effort
15:09:14 <jkurik> people only need to nominate them self
15:09:43 <langdon> another model would be to just change the charter to be "any one at the meeting can vote" .. which i might be fine with too.. unfortunately (and this is probably partially my fault), we haven't been using the ML as much as we probably should..
15:10:01 <jkurik> and the people who nominates , will probably need to publish some answers to a set of common questions
15:10:56 <jkurik> the rest is a work for Election wrangler, who will do the work anyway for other WGs
15:11:26 <langdon> ok.. so .. do we want to vote? anyone want to propose any changes to governance?
15:12:20 <jkurik> I am -1 for including this WG into the F24 Election cycle
15:12:55 <langdon> jkurik, because you just don't feel it is necessary?
15:13:00 <sct> I am -1 for changing the governance
15:13:02 <jkurik> langdon: yes
15:13:16 <tflink> -1 on changing governance
15:13:20 <langdon> ok.. typing proposal..
15:13:31 <dgilmore> sorry I am late
15:13:33 <sct> simply because I think it's an odd practice to allow the quorate membership of the WG to decide for themselves that they don't need reelecting to stay another term.
15:13:45 <langdon> sct, lol.. pshaw
15:14:26 <sct> But I do agree with jkurik that it won't achieve much, so it's not a strong -1... maybe a -0.3 or so. :)
15:14:34 <jkurik> sct: I will include the WG members to F25 Election cycle, it is IMO just too early to do the elections now
15:14:46 <langdon> sorry .. 1 q.. ^^
15:14:50 <contyk> I don't mind either way
15:14:55 <langdon> yeah.. ok.. was typing that in the proposal
15:15:03 <langdon> #info proposed Modularity WG will skip this election cycle as the most recent one was ~6m ago. Plan to participate in next cycle (f25).
15:15:04 <sct> I'm trying to recall --- I think when we set up the WG we said we'd be re-electing anyway, didn't we?
15:15:06 <tflink> i suspect that this is obvious but if we do skip the F24 cycle, it'd need to be the only one we skip
15:15:29 <jkurik> tflink: that is the plan
15:15:42 <langdon> ok.. vote on ^^
15:15:49 <tflink> yeah, i should have waited 30 seconds :)
15:15:51 * langdon means the #info above
15:16:07 <jkurik> ack
15:16:33 <dgilmore> langdon: there has never been a Modularity WG election right?
15:16:48 <langdon> dgilmore, well.. there was sorta one at the beginning..
15:16:50 <dgilmore> not sure that has been elections for any WG's
15:16:56 <langdon> "election by fiat" :)
15:16:57 <lkocman> dgilmore: there was a democratic decision which involved very little democracy
15:17:06 <langdon> lkocman++
15:17:06 <zodbot> langdon: Karma for lkocman changed to 3 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:17:07 <lkocman> but it was a great Election
15:17:12 <lkocman> big one
15:17:28 <sct> Where Langdon was the big one who made the decision. :)
15:17:31 <langdon> ok.. i have one in favor.. anyone else?
15:17:31 * lkocman plays on trump
15:17:47 <sct> -1 but a weak -1
15:18:02 <langdon> sct, i thought you did not want an election.. ?
15:18:23 <sct> langdon: No, I didn't want to change the governance
15:18:29 <langdon> sct, ahh ok
15:18:43 <sct> we had the same question being proposed with opposite polarity. :)
15:19:04 <langdon> ha
15:19:16 <langdon> ok.. this is gonna take forever.. in favor of election, quickly +1 or -1 ??
15:19:17 <dgilmore> https://admin.fedoraproject.org/voting/archives
15:19:28 <jkurik> -1
15:19:35 <tflink> -1 but also weak - it just seems strange to say "we can continue without an election"
15:19:39 <sct> I don't think the WG really needs it, as jkurik says; but I think it's generally better for Fedora if the WGs have elections
15:19:50 <dgilmore> Env and stacks seems to be the only thing similiar to a WG that has had an election
15:19:59 <lkocman> -1 I don’t see a big need for re-elect
15:20:00 <tflink> sigh
15:20:00 <dgilmore> what does our charter say?
15:20:03 <tflink> i misread
15:20:14 <tflink> +1 but also weak - it just seems strange to say "we can continue without an election"
15:20:53 <tflink> +1 on having the election - yes, it's probably not going to do much, but it seems strange to have effectively appointed people say "we can continue without actually being elected"
15:20:57 <langdon> by way of comparison.. server doesn't have elections.. just named people based on participation (badly paraphrased and some IIRC)
15:21:11 <sct> tflink: I think the +1 is for _not_ having it??
15:21:12 <dgilmore> -1
15:21:19 * langdon digs for charte
15:21:20 <langdon> r
15:21:24 <tflink> sct: it was phrased both ways
15:21:24 <sct> Oh
15:21:27 <sct> new question
15:21:28 <dgilmore> langdon: none of the Working Groups have elections
15:21:31 <sct> +1 for election
15:21:43 <sct> but I think it will be a formality
15:21:50 <sct> weak +1
15:21:52 <dgilmore> I am -1 for elections
15:21:54 * langdon points out it is easier to get what i want if i keep rephrasing the q ;)
15:21:58 <sct> if that's what's in our charter
15:22:09 <dgilmore> sct: there is nothing in the charter
15:22:16 <dgilmore> https://fedoraproject.org/wiki/Modularity_Working_Group/Governance_Charter
15:22:19 <langdon> "Each voting member of the working group will confirm their continued membership every six months. In the event that a current voting member relinquishes their seat, the remaining voting working group members are responsible for appointing a new voting member to fill the seat from the active Fedora Server community via majority consensus. "
15:22:25 <lkocman> weak +1 for democratic elections then
15:22:34 * langdon just noticed typo
15:22:41 <dgilmore> langdon: so no fracking elections
15:22:44 <dgilmore> lets move on
15:22:49 <langdon> yeah!!
15:22:51 <langdon> :)
15:23:13 <sct> langdon: OK.  It's -1 to making an exception.  If the charter lets us just move on, then let's just move on.
15:23:19 <langdon> ok.. so.. proposed: per the charter, no fracking elections! (will paraphrase for agreed) :)
15:23:25 <sct> +1
15:23:26 <dgilmore> +1
15:23:28 <tflink> +1
15:23:33 <jkurik> +1
15:23:37 <lkocman> +1
15:24:16 <langdon> #agreed per the modularity working group charter (https://fedoraproject.org/wiki/Modularity_Working_Group/Governance_Charter), modularity WG will not be participating in the f24 elections.
15:24:33 <langdon> ok.. next.. one sec will i c/p
15:24:35 * jkurik is sorry for taking almost half of the timeslot for this meeting with his topic
15:24:41 <langdon> #topic demos sprint 7
15:24:45 <langdon> jkurik, :)
15:25:01 <langdon> jkurik, if any of us remembered the charter already answered this ...
15:25:08 <langdon> cpacheco, want to do the honors?
15:25:14 <cpacheco> Sure
15:25:53 <cpacheco> For sprint #7, we recorded a handful of demos and uploaded them to YouTube, which you can find here: https://www.youtube.com/watch?v=-TIrQ6_bwEk&list=PLcwHJG45BmANGOBocdSTOC7220A9Fd_vH
15:26:17 <cpacheco> You can also find the individual demo videos here: https://fedorapeople.org/groups/modularity/sprint-7-demo/
15:26:47 <cpacheco> All the videos in the playlist are in a specific order, so it is recommended that you watch the videos in the order in which they appear in the playlist
15:27:07 <cpacheco> As always, you are more than welcome to give us feedback on these videos
15:27:10 <langdon> and, cpacheco will be posting an "overview" video to the playlist by tomorrow?
15:27:17 <cpacheco> Yes, I will be posting an overview video
15:27:25 <langdon> and .. also.. has awesomely added ones for the last two sprints
15:27:27 <cpacheco> I posted overview videos for both sprint #5 and sprint #7
15:27:28 <langdon> cpacheco++
15:27:28 <zodbot> langdon: Karma for cpacheco changed to 2 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:28:03 <lkocman> also adding to meeting … let’s just do sprint demos after sprint, not during it if we can post overview day after why not the rest ...
15:28:05 <cpacheco> Essentially, the "overview" video is a 3-5 minute video that describes what we did during the sprint and how all the demos relate to each other
15:28:24 <lkocman> yup
15:28:30 <langdon> cpacheco, you did #5 and #6 already, right? not #7
15:28:37 <cpacheco> Yes, 5 and 6, but not 7
15:28:43 <cpacheco> 7 is coming out by EOD
15:28:45 * langdon notes typo abover
15:28:57 <cpacheco> ah, yes. i meant 5 and 6 :)
15:29:32 <cpacheco> Demo 5 overview (for anyone who is interested): https://www.youtube.com/watch?v=xtxB2O7HudE
15:29:46 * langdon was just digging for that
15:29:49 <lkocman> cpacheco: This video is private.
15:29:52 <cpacheco> Demo 6 overview: https://www.youtube.com/watch?v=MWmDC75Q5A0
15:29:52 <langdon> can you give us #6 too?
15:30:02 <cpacheco> ah, i'll make them public now. i thought they were public
15:30:03 <langdon> oops.. i was supposed to flip that bit
15:30:07 * cpacheco makes them public
15:30:31 <langdon> #link https://www.youtube.com/watch?v=xtxB2O7HudE < sprint #5 overview video
15:30:38 <lkocman> nice!
15:30:42 <cpacheco> They are now public
15:30:52 <langdon> cpacheco, link to 6?
15:30:58 <cpacheco> But anyway, those "overview" videos are the type of thing you should expect with sprint #7
15:31:15 <cpacheco> langdon: https://www.youtube.com/watch?v=MWmDC75Q5A0
15:31:31 <langdon> #link https://www.youtube.com/watch?v=MWmDC75Q5A0 < sprint #6 overview video
15:31:44 <langdon> ok.. any qs about demos? or should we move on?
15:31:55 <cpacheco> yes, one more thing...
15:32:06 <langdon> btw.. detailed links to videos (non-yt versions) are in the agenda
15:32:13 <cpacheco> Assume the "overview" video for sprint #7 will be added to the sprint #7 playlist
15:32:21 <cpacheco> so the link to the video can be found there
15:32:31 <cpacheco> but it's not up yet
15:32:40 <langdon> #info For sprint #7, we recorded a handful of demos and uploaded them to YouTube, which you can find here: https://www.youtube.com/watch?v=-TIrQ6_bwEk&list=PLcwHJG45BmANGOBocdSTOC7220A9Fd_vH
15:32:56 <langdon> #info detailed links to videos (non-yt versions) are in the agenda (http://piratepad.nl/modularity-wg-agendas)
15:33:04 <langdon> ok.. next topic
15:33:13 <langdon> #topic sprint 8 theme
15:33:47 <langdon> ok.. we are trying to start doing a theme for each sprint.. YMMV .. but we think it will help make what we are doing make more sense for people who aren't there everyday
15:34:06 <langdon> so.. for our first attempt at it.. we are going to do "orchestrator" as the theme..
15:34:38 <langdon> as you may recall from threebean's diagram.. there is a "thingy" that orchestrates builds in koji (and some other stuff) it is in the middle of the diagram
15:34:41 <lkocman> Říďa is the codename for orchestrator
15:34:52 <langdon> so.. we will be taking a crack at it for this sprint..
15:35:11 <lkocman> langdon: in a limited effort right? since 1/2 people is on pto
15:35:45 <langdon> we will also be publishing some new arch docs (courtesy of sct), some UX thought from mary, and, hopefully, some ideas on "what is a releasable module" from robert
15:36:08 <langdon> lkocman, sure.. i expect it to still be awesome though! :)
15:36:15 <langdon> so..
15:36:27 <contyk> of course it will be
15:36:43 <langdon> #info sprint 8 theme is: orchestrator, prelim UX, new arch docs, and prelim QE
15:36:46 <lkocman> langdon: with threebean backing us … it will rock!
15:36:52 <langdon> lkocman, :)
15:36:56 * threebean cartwheels into the room
15:37:00 <lkocman> :-)))
15:37:16 <langdon> any thoughts? questions? /me notes next topic is about orchestrator itself.. so hold qs about that for then
15:37:37 <lkocman> threebean: langdon do we want to just post some rendered png out of our dia?
15:37:54 <langdon> lkocman, next topic then yes
15:38:23 <langdon> ok.. tflink in particular i would like to make sure you see robert's thoughts asap
15:38:37 <langdon> ok.. moving on
15:38:40 <langdon> #topic orchestrator
15:38:56 <langdon> contyk, lkocman threebean one of y'all want to take it away?
15:39:04 <langdon> #chair contyk lkocman threebean
15:39:04 <zodbot> Current chairs: contyk langdon lkocman threebean
15:39:13 <contyk> yeah, so the basic idea is this
15:39:16 <contyk> http://fed-mod.org/rida.png
15:39:38 <contyk> the orchestrator, codenamed rida, as lkocman has already said, coordinates the build of the module and all the components it contains
15:39:55 * langdon realizes he screwed up the chair command earlier
15:39:58 <contyk> it provides a RESTful interface the packager interacts with the usual tools as as fedpkg
15:40:00 <langdon> #chair: dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink, threebean
15:40:00 <zodbot> Current chairs: : contyk cydrobolt dgilmore harald jkurik langdon lkocman mikedep333 sct tflink threebean
15:40:08 <lkocman> aka non-atomic chainbuild based on yaml passed as scmrul … with tracking progress and sprinkles
15:40:09 <contyk> ;)
15:40:16 <lkocman> *scmurl
15:40:26 <contyk> yeah, that :)
15:40:38 <threebean> with buildroot, target, and tag construction too!
15:40:47 <langdon> diagram here?
15:40:49 <lkocman> yup … target per module/version/release
15:40:58 <lkocman> langdon: rida.png above?
15:41:03 <langdon> oh sorry.. didn't see the link above
15:41:09 <lkocman> langdon: apologize accepted
15:41:14 <langdon> one of you #link that now that you are chairs please
15:41:20 <jkurik> #link http://fed-mod.org/rida.png
15:41:56 <contyk> so, yes -- modules are represented as targets in koji
15:42:04 <contyk> and we track the deliverables in pdc
15:42:12 <lkocman> the PDC is involved as dependency grapher, and also stores the imported module tree location, so we can compose it
15:42:16 <lkocman> yup
15:42:18 <contyk> rida has its own database which tracks module build states
15:42:47 * dgilmore wants to point out the cost of new targets and buildroots in koji today is massive
15:42:47 <lkocman> also let’s say that long term goal is to get module into koji. this is a prototype
15:42:58 <lkocman> ack
15:43:04 <dgilmore> it needs major redesign in order to not cause massive issues
15:43:26 * dgilmore thinks you should look at teh koji work first
15:43:30 <lkocman> dgilmore: I see it as continuous rebuild of all the things :-)
15:43:38 <langdon> dgilmore, et al.. needs major work to fit this proposal? or the longer term version?
15:43:58 <dgilmore> langdon: for more than about 2 modules
15:44:32 <dgilmore> if we are going to do one or two we can wear the cost, pain and slowness
15:44:43 <dgilmore> but more than that kojisra will not scale
15:44:54 <dgilmore> kojira
15:45:08 * threebean nods
15:45:17 <threebean> yeah, that work is just on our plate dgilmore
15:45:20 <threebean> but not for this sprint.
15:45:37 <threebean> we want to see if we can even build modules in koji (with this Rida orchestrator)
15:45:43 <langdon> well.. will we be able to "stage build a module" by flock?
15:45:52 <threebean> and, if it works (slowly) then next sprint (or the one after that) we can dive into optimizing koji.
15:46:19 <threebean> I put a good bit of work in last week on the koji test suite (not nearly finished) in preparation for that.
15:46:44 <contyk> +1
15:47:04 <threebean> but, no one is going to solve that for us.
15:47:12 <threebean> it's the modularity team's problem to solve.
15:47:22 <threebean> (just want to make that clear)
15:47:32 <tflink> $a
15:47:35 <tflink> bah
15:47:51 <lkocman> dgilmore: I think that the proposal is dozens of modules over time
15:48:02 <langdon> so.. i am not sure i follow.. the concern here is that koji can't handle the orchestrated builds either? i thought the concerns were more about making modules a first class citizen of koji?
15:48:37 <threebean> langdon: they're two separate concerns.
15:49:04 <threebean> dgilmore is concerned about choking koji.  in other meetings, I've been concerned about the first-class citizen status of modules in koji.
15:49:22 <contyk> the latter is still our long term goal, ftr
15:49:23 <langdon> well.. not to be too petulant :) but "will we be able to build arbitrary modules for people by flock?" even if in stg?
15:49:54 * threebean nods
15:49:56 <threebean> one or two
15:49:57 <lkocman> langdon: that’s what your demo is about. Make it happen :-P
15:50:14 <threebean> yeah, the optimization work we can hold off on.  but we can't go to "production" without it.
15:50:19 <langdon> lkocman, *you* are making my demo happen! ... all i do is wave my hands a lot :)
15:50:21 <dgilmore> langdon: stag koji has almost no r4esources
15:50:24 <dgilmore> resources
15:50:37 <lkocman> dgilmore: we do expect core by flock right?
15:50:40 <contyk> langdon: buy more servers ;)
15:50:47 <dgilmore> I am more concerned about choking stage koji than production koji
15:51:00 <dgilmore> lkocman: I have no idea
15:51:15 <dgilmore> langdon: we have 2 arm servers
15:51:19 <lkocman> langdon: ^ can you promise dgilmore that we won’t choke stage to death?
15:51:22 <dgilmore> and I think 6 x86 vms
15:51:37 <langdon> well.. in a sense.. the choking is about "rebuilds" right.. like deps and modules needing to be rebuilt.. building one module at a time.. like not being abale to share much may be less damaging?
15:51:37 <dgilmore> thats the full capacity of stg koji
15:51:46 <dgilmore> it also has limited disk space
15:51:49 <lkocman> dgilmore: let’s do this … we can have our stuff in modularity channel
15:52:01 <lkocman> dgilmore: we’ll add just one builder to modularity … with capacity at least 4
15:52:08 <lkocman> and use just that and leave rest free
15:52:21 <dgilmore> /dev/mapper/GuestVolGroup00-root                                 242G  183G   59G  76% /
15:52:22 <lkocman> dgilmore: or if it’s 6 then … let’s say two hosts in channel
15:52:23 <threebean> then there'll be space left over for all the other stg users (koschei, pungi,...)
15:52:38 <dgilmore> there is 59G of 242G disk available
15:52:47 <langdon> well.. and .. let's talk about the design.. we can always throttle usage.. as long as the design is ok, right?
15:52:54 <dgilmore> lkocman: there is 2 arm boxes
15:52:58 <dgilmore> just 2
15:53:16 <langdon> like is there really a way to design it much differently in light of limited resources? i would think not.. it is just about throttling
15:53:33 <threebean> langdon: +1
15:54:02 <contyk> langdon: +1
15:54:06 <langdon> so.. let's agree on the design.. and then get it running and see what damage it actually does.. then x the throttling (or more servers) bridge?
15:54:06 <dgilmore> langdon: sure
15:54:28 <langdon> (where "x" = "cross" .. sorry old habit)
15:54:39 <threebean> so, a comment on the design
15:54:57 <threebean> its unique among the kinds of things we build... because fedpkg module-build talks directly to rida
15:55:08 <threebean> but when we container build or image build or do a normal build.. all those things talk directly to koji
15:55:23 <threebean> which either handles building that content as a native task *or* hands it off to a content-generator.
15:55:42 <threebean> so, we're doing things differently here mostly just so we can get things going faster (prototype phase)
15:55:55 <threebean> we want to instead reorganize things to be more in line with our other content types down the road (post flock)
15:56:19 <threebean> that's important because it limits the scope of development we do on Rida.
15:56:21 <langdon> threebean, are you saying "more in line" is to talk directly to koji? or the opposite?
15:56:27 <threebean> langdon: talking to directly to koji.
15:56:37 <lkocman> threebean: that’s next step once the prototype is done isn’t it?
15:56:41 * threebean nods
15:56:45 <langdon> threebean, this seems to be a bus problem to me :)
15:56:49 <threebean> yeah, we know that lkocman.
15:56:58 <threebean> lkocman: I'm just saying it again for the meeting :p  (we talked about it this morning)
15:57:03 <lkocman> I see your concern. but I just really got this as recommendation from mikem
15:57:30 <lkocman> I asked whether we should start with injecting it into koji
15:57:38 <threebean> let's double back and check with him again now that we understand more about the whole thing.  fair?
15:57:42 <langdon> does fedpkg need a sync response? why not just post a message and have either rida or koji pick it up?
15:57:59 <threebean> langdon: -1, no publishing to the bus from outside infra.  we don't have a way to secure it.
15:58:02 <lkocman> yup
15:58:09 <dgilmore> threebean: I had a discussion yesterday with mikem where I outlined the issues I have with content generator, and honestly the same arguments apply here I think
15:58:10 <lkocman> threebean: ddos langdon !!! ddos!
15:58:20 <contyk> langdon: it only gets a response like "200 OK, submitted"
15:58:33 <threebean> dgilmore: do you have notes on that?
15:58:37 <langdon> i didn't realize there wasn't a secure channel to post to the bus..
15:58:42 <dgilmore> threebean: acarter may
15:59:04 <threebean> langdon: we have to give you a secret cert, and lock you down with iptables... and we just can't do that for end users.
15:59:15 <threebean> dgilmore: will follow up after the meeting.  thanks.
15:59:21 <langdon> threebean, i guess we kinda do that with packagers, no?
15:59:31 <threebean> langdon: well, they talk to koji via XMLRPC.
15:59:39 <contyk> and koji then spams the bus
15:59:44 <langdon> contyk, lol
15:59:59 <threebean> and that's my original point.  adding rida as a web service increases our web API surface.
16:00:06 * dgilmore has to run to the releng demo
16:00:19 <langdon> yeah.. probably time for us to wrap up
16:00:20 <threebean> if we can keep that smaller - and have fedpkg just talk to koji like everything else does.. that keeps the surface simple.
16:00:20 * lkocman needs to run for another super secret project
16:00:26 * threebean waves
16:00:27 <langdon> anything #agreed or #info we can note?
16:00:27 * dgilmore is likely to not be here the next 4 weeks, it will be a 1am start time for me
16:00:35 * lkocman +1
16:00:41 <threebean> dgilmore: we'll make sure to wreck the world for you while you're gone.
16:00:53 <dgilmore> threebean: I jnow what city you live in
16:00:58 <dgilmore> know even
16:00:58 * threebean curses
16:01:18 <langdon> ok... closing things down
16:01:26 <langdon> see above ^^
16:01:34 <langdon> going once....
16:01:50 <langdon> going twice..........................
16:02:05 <langdon> going thrice.....
16:02:14 <langdon> #endmeeting