13:02:33 <mmaslano> #startmeeting Env and Stacks (2014-07-29)
13:02:33 <zodbot> Meeting started Tue Jul 29 13:02:33 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:39 <mmaslano> #meetingname env-and-stacks
13:02:39 <zodbot> The meeting name has been set to 'env-and-stacks'
13:02:44 <mmaslano> #chair pkovar tjanez samkottler bkabrda hhorak juhp mmaslano vpavlin sic
13:02:44 <zodbot> Current chairs: bkabrda hhorak juhp mmaslano pkovar samkottler sic tjanez vpavlin
13:03:01 <hhorak> Hello
13:03:06 <vpavlin> Hi
13:06:37 <mmaslano> I hope there will be more attendees
13:08:18 <hhorak> Even if not, I see tflink and EdSantiago online, which would be great combination to talk about rpmgrill vs. taskotron
13:08:25 <bkabrda> hi everyone, sorry I'm late
13:09:26 <mmaslano> #topic init process
13:09:38 <mmaslano> #topic rpmgrill vs taskotron
13:09:44 <mmaslano> EdSantiago: hi
13:09:54 <mmaslano> tflink: hi too
13:09:58 <EdSantiago> mmaslano, hi
13:11:26 <hhorak> from mail we exchanged between Ed and me there are currently few questions:
13:11:58 <hhorak> first, rpmgrill consumes quite a lot of resources -- CPU/disk (and if downloading packages from koji, then also network, but I guess this should be done by taskotron) -- will taskotron be capable of running such utility?
13:12:43 <hhorak> ^ tflink could probably comment on that -- are you around by any chance?
13:17:11 <hhorak> Hm, it does not seem like tflink is around today, so I'll contact him after the meeting.
13:18:30 <mmaslano> hhorak: so another question?
13:18:36 <hhorak> another question is a desired search capability for rpmgrill results: search by package (for people who own packages) and by test (for people with a strong interest in particular test failures, eg security folks)
13:18:42 <bochecha> hhorak, it's 7am for tflink right now, might just need to wait a bit ;)
13:19:09 <hhorak> bochecha: thanks, I haven't realized that :)
13:19:32 <hhorak> as for the results question -- I guess this is something taskotron's resultsdb should support generally.
13:20:12 <hhorak> tflink already said that resultsdb will need many changes, so this should be covered by new RFEs.
13:22:06 <hhorak> What I'm worrying about is granularity of tests -- EdSantiago do I understand rpmgrill correctly that it has two levels of tests results? that first level is module and second level is test name?
13:22:18 <mmaslano> EdSantiago: are you interested in co-operation with taskotron?
13:22:34 <mmaslano> EdSantiago: I guess that's the first question :)
13:23:14 <EdSantiago> hhorak: re: "two levels": it's not exactly two levels of _results_. Each plugin (BuildLog, ElfChecks, etc) is one module which can issue one or more failure codes
13:24:01 <hhorak> EdSantiago: ok, than we should not need bigger granularity I guess
13:24:18 <EdSantiago> hhorak: re: cooperation: yes, for now, but I still need to learn more & find out how it'll work with my time constraints.
13:28:34 <EdSantiago> hhorak: re: plugins, from the developer PoV each plugin is a separate source file; from an end-user PoV it might make more sense to just think of the codes as grouped/classified under comon themes
13:30:43 <hhorak> EdSantiago: ok, but from a results POV the tests should be taken as separate tests, right?
13:31:23 <hhorak> EdSantiago: I mean no matter which plugin they came from.
13:32:14 <EdSantiago> hhorak: I'm not sure how to think about that. Say IntegerOverflow - it only makes sense in the context of the BuildLog plugin (umbrella, whatever), i.e. the test that analyzes the build log
13:33:13 <hhorak> EdSantiago: understood
13:33:21 <EdSantiago> hhorak: maybe if you think of it as each plugin is a test which can issue messages/gripes/warnings using a specific code?
13:36:10 <hhorak> EdSantiago: yeah, that was actually a feeling I had. I'm not sure though if the searching capability needs to know about the plugin, which the warning came from.
13:37:53 <EdSantiago> hhorak: except for one thing - the grouping can be useful if someone wants to see (e.g.) all results from the SecurityPolicy test
13:38:29 <hhorak> EdSantiago: good point, that could be helpful
13:38:53 <EdSantiago> hhorak: I've just added tooltips to the search page http://rpmgrill-fc20.edsantiago.com:5000/search
13:40:19 <mmaslano> hhorak: hm could make meeting minutes from that? :)
13:40:35 <hhorak> mmaslano: sure
13:40:59 <hhorak> I have the last thing probably anyway -- regarding the two options we have -- keeping rpmgrill totally separately or integrating it with taskotron -- I think we should try to go with the integrating for now and only if it turns to be problematic we should start to maintain a separate system for rpmgrill. EdSantiago, does this seem fine for you?
13:41:51 <EdSantiago> hhorak: yes, that seems reasonable. What will you need from me?
13:44:26 <hhorak> EdSantiago: I have nothing specific right now but I think something will come up as soon as someone (hopefully me) will start to write plugin for taskotron
13:45:38 * EdSantiago kicks back and relaxes on a hammock
13:46:02 <hhorak> EdSantiago: thanks!
13:46:51 <EdSantiago> hhorak: thank you for your efforts on this. I look forward to remaining in touch. (And I'll start learning more about Taskotron)
13:49:14 <hhorak> so to sum it up into the meeting log:
13:49:14 <hhorak> #info rpmgrill consumes quite a lot of resources -- CPU/disk/(network) -- we need to find out if taskotron be capable of running such utility
13:49:14 <hhorak> #info for rpmgrill it would be beneficial if taskotron results could be grouped by their desire (groups like SecurityPolicy, BuildLog)
13:49:14 <hhorak> #info current rpmgrill search with tooltips is here: http://rpmgrill-fc20.edsantiago.com:5000/search
13:49:14 <hhorak> #info we'll should try to go with the integrating of rpmgrill into taskotron for now and only if it turns to be problematic we should start to maintain a separate system for rpmgrill
13:49:14 <hhorak> #task hhorak will start to write taskotron task for rpmgrill finally
13:49:58 <hhorak> #task hhorak will contact tflink to consult those ^
13:51:59 <hhorak> Sorry to hijack big part of the meeting, do we have something else to talk today?
13:52:09 <mmaslano> yes, docker
13:52:15 <mmaslano> vpavlin: do we have any update from last week?
13:52:20 <mmaslano> #topic docker
13:52:29 <mmaslano> #undo
13:52:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x132b4110>
13:52:33 <mmaslano> #topic docker & copr
13:52:47 <vpavlin> BaseWG voted and decided to own base images
13:52:51 <mmaslano> vpavlin: i didn't say anything about your graph, because Mirek should talk first :)
13:53:04 <mmaslano> #info BaseWG voted and decided to own base images
13:53:19 <vpavlin> Koji is almost ready, I've talked to Dennis Gilmore and sent a patch for base image ks
13:53:36 <vpavlin> So we should have official Fedora base images soon(ish)
13:53:38 <vpavlin> :)
13:53:53 <vpavlin> To the copr proposal..
13:53:55 <vpavlin> I've created a diagram describing how the layered image build service could work
13:53:56 <vpavlin> #link https://vpavlin.fedorapeople.org/copr-docker.svg
13:53:59 <mmaslano> sounds great
13:54:14 <vpavlin> And here is a description and proposal for extending copr API output so that it's possible to create Dockerfile - we might not want to build the image at first, but only generate the Dockerfile and provide it to the user so that he can just do docker build $link_to_dockerfile - it would be quite easy to implement and wouldn't be heavy on infrastructure
13:54:14 <vpavlin> #link https://vpavlin.fedorapeople.org/build.json
13:55:03 <vpavlin> I also asked Openshift guys to have a look at this RFE and they are quite interested - I am meeting them in an hour to talk about possible collaboration.
13:55:24 <vpavlin> the json file is not posted anywhere yet - I will post it to copr-devel ML after the meeting with Openshift
13:57:08 <vpavlin> Anyway I didn't get any response apart from comment that this shouldn't be part of copr and should be a separate service:)
13:57:17 <vpavlin> (on copr-devel)
13:58:41 <mmaslano> :)
13:58:53 <mmaslano> yeah, I was looking forward to some decision
13:59:26 <mmaslano> msuchy didn't reply, so I would wait for him be back and reply
13:59:41 <mmaslano> without his opinion the discussion doesn't have much value
13:59:42 <vpavlin> sure
13:59:53 <hhorak> vpavlin: separate service means a separate copr instance?
14:02:07 <vpavlin> hhorak: No, the building service should be separate from copr - and should be either called by some API or react to fedmsg evetns
14:02:11 <vpavlin> *events
14:03:40 <mhroncok> jreznik suehle spot: moving somewhere else?
14:03:52 <suehle> Yeah, let's go to #fedora-meeting-1
14:03:53 <spot> mhroncok: go to #fedora-meeting-1
14:04:48 <mmaslano> I'm out of topics
14:04:51 <mmaslano> anything else?
14:08:22 <mmaslano> #endmeeting