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