14:01:47 <tflink> #startmeeting fedora-qadevel 14:01:47 <zodbot> Meeting started Mon Mar 14 14:01:47 2016 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:47 <zodbot> The meeting name has been set to 'fedora-qadevel' 14:01:47 <tflink> #topic Roll Call 14:01:53 * kparal is here 14:02:01 <linuxmodder> of course I do all the time I volunteer at several youth community centers 14:02:08 * linuxmodder here 14:02:13 <linuxmodder> .fas corey84 14:02:13 <zodbot> linuxmodder: corey84 'Corey Sheldon' <sheldon.corey@gmail.com> 14:02:14 * garretraziel is here 14:02:21 * mkrizek 14:02:51 * tflink was not jokingly referring to one the justifications for DST that we shouldn't have kids waiting for the school bus in the dark 14:03:05 * jskladan waves 14:03:21 * lbrabec is here 14:03:25 <tflink> happy start to 3-4 weeks where we question the timing of everything! 14:03:45 <tflink> summer time starts in 2 weeks, no? 14:04:40 <kparal> can't we inject illumination genes into kids? there, tech solution 14:04:41 <tflink> anyhow, moving on to things we can change instead of just me whining :) 14:04:56 * tflink lets kparal suggest that one to governments 14:05:07 <tflink> or parents 14:05:30 <kparal> simplifies parental supervision as well! 14:06:12 <tflink> #topic Announcements and Information 14:06:12 <tflink> #info minion->host copy operations were sped up a bit -- kparal 14:06:12 <tflink> #link https://phab.qadevel.cloud.fedoraproject.org/D769 14:06:12 <tflink> #info input arguments for runner and directives were renamed -- kparal 14:06:12 <tflink> #link https://phab.qadevel.cloud.fedoraproject.org/D772 14:06:13 <tflink> #info more attempted debugging of kernel issue that's been killing out virthosts - tflink 14:06:20 <mkrizek> #info finally tracked down the cause of the now famous bug when VMs were not starting - mkrizek 14:07:05 <tflink> the dev virthost hasn't gone belly up since friday, seems like the new kernel worked! 14:07:17 <mkrizek> \o/ 14:07:43 <garretraziel> #info merged changes in task-dockerautotest testsuite - jsedlak 14:07:45 <tflink> which is great because I still don't know why exactly it was happening 14:08:25 <tflink> any other items, comments or questions? 14:09:13 * tflink takes that as a no 14:09:16 <kparal> not here 14:09:34 <tflink> #topic Tasking and Roadmap 14:10:12 <tflink> is anyone in need of task(s) this week? 14:10:27 <tflink> is anyone blocked on anything? 14:10:30 <jskladan> nope, kparal is keeping me busy :-P 14:10:41 * kparal goes into corner 14:10:42 * mkrizek has enough to do 14:10:45 <tflink> he does tend to do that 14:11:01 <kparal> I'm actually interested what is the top priority now 14:11:18 * garretraziel is going to work on dockerautotest trigger and then he will finaly get back to do some openQA :-) 14:11:20 <kparal> I could look into that instead of pestering other people 14:11:26 <jskladan> kparal: sadly, the things you keep me busy with today are quite on the top... 14:11:29 <tflink> mostly dist-git, followed by docker 14:11:55 <tflink> the next topic should help with that, then 14:12:05 <kparal> I could try writing some of the docs T716, but the namespaces were not finalized yet 14:12:40 <kparal> I can at least prepare some skeleton, though 14:12:41 * mkrizek will post updated patch for namespaces tomorrow 14:12:51 <tflink> i think that mkrizek has most of the dist-git stuff under control, didn't really intend for one person to get most of those tasks but it happens :) 14:13:20 <kparal> mkrizek is our hero ;) 14:13:22 <mkrizek> I am happy to share! 14:13:32 * kparal will take T716 14:13:51 <tflink> kparal: the next topic would also be a good one 14:14:03 <kparal> ok, let's see it 14:14:07 <tflink> not quite written up yet, was waiting for some discussion 14:14:26 <tflink> anything else on tasking or roadmap? 14:14:50 <kparal> not here 14:15:14 <mkrizek> nope 14:15:18 <tflink> #topic Docker Image Testing 14:15:40 <kparal> buzzword alert 14:15:44 <tflink> F25 should be bringing layered docker images 14:16:11 <tflink> one of the things that releng wants from us is the ability to run automated tests on those docker images 14:16:40 <tflink> but that runs into a couple of fun bits 14:16:42 <kparal> test those images, or run arbitrary tests on top of those images? 14:16:53 <tflink> 1) what is "testing the docker image"? 14:16:54 <garretraziel> what kind of tests? 14:17:17 <tflink> 2) I'm not sure if anyone else is doing this much. 14:17:30 <tflink> garretraziel: that's one of the open questions I'm trying to get answered 14:18:07 <tflink> it's still pretty unclear but regardless of the details, we still need to have a way to run these image specific tests 14:19:16 <tflink> which, in my mind, means one of a few things: find a framework/system that is capable of "testing" docker images or make something (hopefully generic) work 14:19:35 <tflink> er, one of two things 14:19:59 <tflink> i figured that this could tie back into the generic test runner 14:20:21 <kparal> so this is not just about running an existing test suite, but also writing the test suite (for layered docker images)? 14:20:39 <tflink> since the current thinking is that so long as we allow image authors to start up containers and poke at them with few restrictions, it should be fine 14:20:59 <tflink> no, I haven't signed us up to write the tests, as far as I know 14:21:09 <kparal> ok, that's good 14:22:32 <tflink> kparal: my thought was to start looking into what our options are in more detail 14:23:32 <kparal> I still don't completely understand what this is all about 14:23:43 <kparal> but maybe just because I never used docker 14:24:11 <tflink> as i understand it, there's a desire to have automated testing of the layered docker images released by Fedora 14:24:11 <kparal> good that we have at least two docker gurus here :-) 14:24:37 <tflink> as the number of those is going to start growing after F25 14:25:06 <kparal> so, can we use the same approach as with task-dockerautotest, just write a python wrapper for their test suite? 14:25:13 <garretraziel> me neither; we want to find "something" that will enable people to test docker images itself? e. g. someone writes test that tests whether apache starts on newest server docker image and we want something so we would be able to run this test on docker automatically? 14:25:21 <tflink> kparal: that doesn't really scale well 14:25:35 <kparal> tflink: what do you mean? 14:25:53 <tflink> kparal: writing a wrapper for every test suite that comes in? 14:26:17 <tflink> the primary idea at this point is to enable automated checks against docker images 14:26:46 <kparal> I understand that we might want a generic wrapper that is easier to use than libtaskotron test wrappers 14:26:49 <tflink> putting as few limitations on what those checks are as we reasonably can 14:27:02 <kparal> but that's not tied to this layered docker test, is it? 14:27:06 <kparal> that's a generic problem 14:27:20 <tflink> it might be 14:27:31 <kparal> or are you saying "now is the best time to start working on a generic runner"? 14:27:48 <tflink> note that at this point, it's just gathering information and options 14:28:06 <tflink> my thought was to solve this in one of 2 ways 14:28:22 <tflink> 1) find something out there currently used to "test docker images" and re-use that 14:28:59 <tflink> 2) work on a more generic runner we can use in more situations and add some hooks/macros for starting/stopping/etc. docker images 14:29:54 <tflink> I'm not aware of anything that falls into 1) and I suspect that we'll end up doing 2) 14:29:56 <kparal> I think we'll need to discuss outside of the meeting in more detail, because I still have too many open questions. like whether we're going to sidestep our task formula and resultsyaml somehow 14:30:26 <tflink> ok 14:30:58 <tflink> sorry, trying to get this started on minimal details so we don't wait too long 14:31:10 <tflink> F25 will be here before we know it 14:32:23 <tflink> any other in-meeting thoughts on this? 14:32:25 <kparal> no problem, it's good to know what's ahead 14:32:41 <kparal> I'll leave my questions for later :) 14:33:37 <tflink> ok, moving on to ... 14:33:45 <tflink> #topic Open Floor 14:33:55 <tflink> anything else which folks want to cover here? 14:34:23 <kparal> I noticed linuxmodder applied to https://admin.fedoraproject.org/accounts/group/view/qa-taskotron-user 14:34:33 <linuxmodder> wondering if psot mtg someone can help walk me thru getting lay of qa playground so I can be productive 14:34:33 <kparal> I'm not sure what the group is for 14:34:57 <tflink> kparal: nothing at the moment 14:35:12 <jskladan> well, I'd like to discuss some things about T731, but I'm trying to wrap my mind about it first, so I can at least come up with some base for the discussions 14:35:13 <tflink> the thought was for ACLs when we get fancier features in the glorious future 14:35:41 <linuxmodder> T731 ? 14:35:41 <kparal> ok. in that case I might set it invite only and write into description that it's not used at the moment 14:35:43 <kparal> if that's ok 14:35:49 <tflink> #topic T731 - Support image type specification in libtaskotron forumulas 14:36:03 <tflink> kparal: yeah, that's probably wise 14:36:10 <tflink> #link https://phab.qadevel.cloud.fedoraproject.org/T731 14:36:56 <jskladan> there are some things to consider for the start - are we going to have "environment agnostic" tasks? If so, to what extent? 14:37:07 <tflink> hrm, i think that https://phab.qadevel.cloud.fedoraproject.org/T745 will be more useful in the short term 14:37:24 <tflink> jskladan: not sure I understand your question 14:37:28 <jskladan> what I mean by that is - there most certainly are tasks taht do not care about the base-image 'template' used 14:37:42 <jskladan> and I'm quite sure that rpmlint does not care about arch 14:37:42 <tflink> true, I suspect that will be most tasks 14:38:22 <jskladan> but are there test that will not care about the fedora version 14:38:27 <kparal> linuxmodder: let's help you in the #fedora-qa channel outside of the meeting 14:38:34 <jskladan> like - it's ok if it's the latest fedora 14:38:47 <linuxmodder> kparal, works for me 14:39:26 <tflink> i suspect that the primary use case for specifying release version will be "run the f25 branch dist-git tasks on f25, run the f24 branch dist-git tasks on F24" 14:40:02 <tflink> i figured we would have some defaults, like we have with most things like this 14:40:24 <tflink> but it sounds like there's some complication I'm not quite grokking 14:40:29 <kparal> I thought we will have some kind of "default release" and "default environment" defined, and if the task formula does not request something specific, we will use the default one 14:41:23 <jskladan> kparal: tflink: the "complication" is the extent to which we want to do "automagic" (like devising arch/release from the --item), and what kind of capabilities do we want to offer to formula-authors 14:41:49 <jskladan> my initial idea is, that there is a "sane default" (latest release, standard flavor, 64bit) 14:42:03 <tflink> that sounds good to me 14:42:09 <kparal> yes, we'll probably want to automatically devise that from --item in some cases 14:42:33 <jskladan> kparal: well, it's all "not-default" cases, I guess 14:42:41 <tflink> we might want to do oldest release or newest release that's not rawhide or branched 14:42:43 <kparal> handling arch will be even bigger problem 14:43:56 <jskladan> and we'd have "automagic" for when it's reasonable - e.g. for KOJI_BUILD, it's 'simple' to get release and arch 14:44:03 <jskladan> so we could take it from there 14:44:18 <jskladan> I'm not sure about the other types, but that's not so important now, I think 14:44:30 <tflink> compose, maybe 14:45:28 <tflink> but that sounds reasonable for me - work on compose/KOJI_BUILD for now with sane defaults, deal with the others as they come 14:45:52 <jskladan> cool, sounds good 14:46:36 <tflink> does that answer your questions for now? 14:47:03 <jskladan> yeah, I'll write something down in the ticket, and we can continue the discussion there 14:47:14 <jskladan> thx 14:47:52 <tflink> sounds good 14:48:18 <tflink> #topic Open Floor 14:48:24 <tflink> other things for open floor? 14:48:41 <kparal> nope 14:49:21 * tflink sets the fuse 14:50:27 <tflink> boom 14:50:32 <tflink> thanks for coming everyone 14:50:36 * tflink will send out minutes shortly 14:50:40 <tflink> #endmeeting