14:00:16 #startmeeting fedora-qadevel 14:00:16 Meeting started Mon May 15 14:00:16 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:16 The meeting name has been set to 'fedora-qadevel' 14:00:16 #topic roll call 14:00:23 * mkrizek is here 14:00:29 who all's here for the meeting? 14:00:56 * jskladan is here 14:01:25 * lbrabec is here 14:01:29 #chair mkrizek jskladan 14:01:29 Current chairs: jskladan mkrizek tflink 14:01:56 * kparal is here 14:02:43 * garretraziel is here 14:02:52 roshi: you around? 14:03:24 * tflink needs help with his kamehameha 14:03:30 * roshi is 14:03:36 anyhow, let's get this party started 14:03:38 sorry I'm late :) 14:03:46 #topic Announcements and Information 14:04:00 #info libtaskotron documentation improvements -- kparal 14:04:08 any other announcements/information? 14:04:37 #info libtaskotron support for ansible task to be posted for review/discussion early this week - mkrizek 14:05:29 any comments/questions? 14:06:03 #info roshi working on getting ansible tasks running against docker containers 14:06:17 roshi: do you think that'll be ready for review today? 14:07:18 it's looking like it 14:07:22 cool 14:07:32 looking forward to seeing both reviews 14:07:37 just trying to get this gzip-dist-git run_tests.yml to run 14:07:51 keeps complaining about libselinux-python not eing installed... :/ 14:08:08 is docker selinux aware? 14:08:18 * tflink feels like he should know this 14:08:46 I think it depends on the container? 14:08:54 makes sense 14:08:57 anyways, there are bunch of things on the agenda today, moving on 14:09:04 #topic F27 14:09:30 This is mostly a heads up to re-iterate the changes which are currently planned to land during F27 14:09:41 1. modularity 14:10:10 this is going to be a big change that's going to touch most parts of Fedora, from what I can see 14:10:36 not sure how it's going to affect Taskotron and the automation bits we're working on but I suspect that it will more at some point 14:11:30 the big potential is the assumptions we make about dist-git and builds that will go away when arbitrary branches lands 14:12:26 the other big one is CI. the CI pipeline is supposed to land as a PoC in November 14:12:53 I'm not sure how much it'll affect us directly other than some support/coordination work 14:13:19 that's most of the big things I'm aware of right now 14:13:25 most/all 14:13:40 any question/comments? 14:14:00 nope 14:14:02 none here 14:14:10 k, moving on then 14:14:17 #topic working with CI folks 14:14:55 There was quite a bit of work around how to take results from CI (running in ci.centos.org) and use them as part of the Fedora release process 14:15:02 last week, I mean 14:15:57 things may still change a bit but the last plans I'm aware of involved putting an execdb instance and possibly a resultsdb instance in centos ci's infra 14:16:28 I started poking at getting us moved over to the new execdb version last week and hit some problems that'll take working around 14:16:41 what were those? 14:16:55 sending requests to variable urls 14:17:46 gave up on trying to make jenkins work with that, trying to figure out a reasonable way to extend buildsteps to make them work together 14:18:16 unless I'm missing something, we'd have to write a custom plugin to make jenkins work with the new execdb 14:18:38 that or find one that I didn't find when I was looking last week 14:19:15 ah, that's a bummer... If it's a real PITA for you to do form Jenkins, I could always just do a data-driven endpoint 14:19:28 I'm not sure that would even work all that well 14:19:38 so you just talk to that one thing, but provide the right data in the queries... 14:19:51 * jskladan shrugs - just a quick idea 14:19:56 let's see how it goes 14:19:58 just getting per-build variables into the request-posting plugins is a challenge 14:20:23 but it'd be worth chatting with someone who knows more about jenkins before writing stuff off 14:20:32 OK, that's beginning to sound like a nice steaming pile... 14:21:01 * tflink shrugs 14:21:05 we'll figure it out 14:21:09 but yeah, as you say - if there's anything we could do to make it more feasible from the execdb side, I'm all for it though - let me know 14:21:36 * tflink is hoping ot get back into the buildstep modification today and will hopefully have some better answers 14:22:12 IIRC, they were happy with resultsdb as-is if they end up using it 14:22:37 there was some talk about using fields in resultsdb for things that I'm not sure about but we'll see what happens 14:22:58 * tflink knows that pingou looked at the execdb diff, doesn't think he had big issues with it 14:23:20 any questions/comments? 14:23:27 not right now 14:23:51 ok, moving on 14:24:07 this feels like it's turning into a brain dump instead of a meeting :) 14:24:13 :D 14:24:17 anyhow, moving on 14:24:34 #topic Future Taskotron Architecture 14:24:46 this is more about longer-term things before getting into the libtaskotron splitting topic 14:25:26 there are a couple of things which will be happening in fedora infra land in the not-so-distant future that could help make Taskotron much better 14:25:31 1. OpenShift 14:25:50 the stg openshift was pretty much working at the end of last week 14:26:32 as in we run taskotron in openshift? 14:26:38 would we get rid of minion spawning and somebody else would handle that? 14:26:40 I'm definitely interested in being a guinea pig for that production deployment assuming we don't find huge architecture incompatibilities 14:26:48 kparal: somewhat 14:26:52 \o/ 14:26:54 but you're getting ahead of me a bit 14:27:19 my big interests are more rapid and frequent deployment 14:27:37 and no (or at least fewer) pet deployments 14:27:48 not that we have that many as it is :) 14:28:02 the next thing is openstack 14:28:25 as I understand it, the hope is to get openstack to be a mostly (if not fully) production service sometime in the next year or so 14:28:40 * tflink would love to delegate VM spawning to openstack 14:29:14 that would remove some headaches from our current setup and could start moving us closer to how the zuul folks do things 14:29:46 we'd still have the testcloud stuff for local execution but not rely on it as much (if at all) in production 14:30:14 do we still aim on being able to have that disposable minion spawned in local/devel usecase, or is that just something completely different? 14:30:28 ah /me is a slow one to write :D 14:30:32 no worries 14:30:56 i think that's going to become less painful with what mkrizek is working on and what I want to do WRT splitting libtaskotron into 3 bits 14:31:24 any questions or comments? 14:31:36 I'm not sure what the timeline on this would be, exactly 14:31:55 tomorrow, by any chance? 14:32:17 yesterday? 14:32:17 kparal: not likely unless you're taking all responsibility for the work and the aftermath 14:32:29 * kparal is not here 14:32:33 lol 14:32:39 what 3 bits? 14:32:40 :) 14:32:52 roshi: that's the next topic 14:33:11 the last thing (that I almost forgot) is about some other infra changes that'll be coming before too long 14:33:34 with all the CI and gating stuff that's coming, resultsdb is going to become a critical bit of Fedora's infrastructure 14:34:12 we didn't make any definite plans, but I suspect that resultsdb may be moving off of our app servers before long 14:34:42 there's also a desire to see it work with BDR (https://www.2ndquadrant.com/en/resources/bdr/) 14:34:45 tflink: does that mean infra is going to maintain resultsdb? 14:34:59 mkrizek: the infra bits, not the code bits 14:35:08 yeah, that's what I meant 14:35:09 cool 14:35:35 and while I'd love to see resultsdb support BDR, that's going to take some work and I'm not sure that's the highest priority ATM 14:36:14 well, that BDR thing will be a PITA to do right (and /me is looking forward to a few days of data migration) 14:36:18 mostly around how resultsdb creates primary keys - you can't (or at least shouldn't if you're sane) use auto-incrementing primary keys with BDR 14:36:40 yeah but it would give us a few important things 14:36:52 hot backups, HA and the potential for more scalability 14:36:54 sure, I'm not at all disputing that 14:37:10 so we're saying pretty much the same thing using different words :) 14:37:22 * tflink doesn't think it'll be just a "change this config and we're good" 14:37:23 but I'll seriously need to look into some stuff before we hit the proverbial "Go" button :) 14:37:32 yep 14:38:02 any comments/questions about all that? 14:38:22 not now, especially if that's not a priority now 14:38:54 getting execdb to work for the ci folks and the next bit about ansible and splitting libtaskotron are the current priorities 14:39:15 ok, moving on to that question :) 14:39:32 #topic Ansible, Test Invocation and Splitting libtaskotron 14:40:13 for some background, there was a proposal to have a standard "interface" through which tests are started 14:40:14 https://fedoraproject.org/wiki/Changes/InvokingTestsAnsible 14:40:40 this proposal has effectively been accepted and the CI folks are planning to use that method of kicking off tests 14:41:06 * tflink has wanted to move from formulas to playbooks for a while and now seems like about the best time to do taht 14:41:29 mkrizek has been working on a patch to remove formulas from libtaskotron and move all execution of tests over to ansible 14:41:36 this gives us a couple of things: 14:41:42 1. less requirement for custom images 14:41:45 tflink: how's directives to ansible modules work going? 14:41:49 2. no nested runner BS 14:42:02 3. Less code to maintain 14:42:11 4. less documentation to write and maintain 14:42:42 mkrizek: on a technical level, it was going well before I went to the FAD last week. I have some new questions about how to get them done, though 14:43:29 one of the things that's occurred to me (and I think mkrizek was thinking something similar) is that we'd be well served to split libtaskotron into 3 packages/bits 14:44:02 1. taskotron-runner - the current executor, responsible for target spawning, kicking off ansible 14:44:24 2. libtaskotron - pure python bits (i.e. koji_utils, bodhi_utils, rpm_utils) 14:44:56 3. fedora-testing-ansible-modules - the custom ansible modules which help folks test fedora (i.e. koji, bodhi) 14:45:18 thoughts? 14:45:59 the ansible modules will depend on libtaskotron then, right? 14:46:20 yep 14:46:43 I'm not against it. Not that I gave that much thought, and I'm sure some practical issues will arise, but from the ideological standpoint - sounds like a good idea, if Ansible is the way forward 14:47:12 yeah, I suspect that we'll be trading our current pain points for some new ones 14:47:28 I don't have any objections either. we'll see what obstacles we discover along the way 14:47:32 less pain overall but there'll be issues :) 14:48:40 we'll see what it ends up like 14:49:03 just put it all in the cloud - docker will make things better :) 14:49:14 oh yeah 14:49:19 no pain at all, there 14:49:33 mostly because roshi is the "cloud guy" in these parts and it'd be _his_ problem :-D 14:49:39 lol 14:50:00 any other comments, questions, concerns etc. ? 14:50:50 * tflink takes that as a no 14:50:54 which moves us on to ... 14:50:57 #topic Open Floor 14:51:23 any other topics that folks would like to bring up? 14:51:31 * roshi has nothing at this point 14:51:42 I've been spending some time improving docs in the last days 14:51:53 I tried to avoid touching formula etc topics, since that's going away 14:52:01 anything else in particular I should avoid? 14:52:25 I can't think of anything in particular, no 14:52:34 but it may all be changing, I suppose :) 14:52:36 e.g. I assume directive docs will still be useful, just move to a different place 14:52:42 yeah 14:53:14 we may end up with way fewer directives/modules, too 14:53:23 also, we should probably start working on proper taskotron-in-fedora docs. how do I submit a task, where can I see results, how do I debug issues, etc 14:53:32 agreed 14:53:41 we have some of that as part of libtaskotron, and most of it missing. we should have it separate, I think 14:54:37 I might try to spend some time on that. what's the preferred approach, a new pagure repo with sphinx/rst files? 14:54:39 I think that publishing a wrapper formula for ansible would be wise for the short term 14:54:52 * tflink doesn't have any strong preferences 14:54:57 either that or wiki 14:54:59 ok 14:56:37 I think that roshi started on something similar that may help 14:56:47 roshi: do you have a link to the stuff you wrote up? 14:57:59 anyhow, we're pretty much out of time 14:58:13 the taskotron overview? 14:58:18 documentation +eleventymillion, though 14:58:20 yeah 14:58:24 jas 14:58:39 https://fedoraproject.org/wiki/User:Roshi/QA/Taskotron_Overview 14:58:41 if there's nothing else, I'll close out the meeting in a minute or two 14:58:49 thanks, will look 14:59:52 patches welcome if I missed details or got something wrong 15:00:21 ok, thanks for coming, everyone 15:00:25 * tflink will send out minutes shortly 15:00:28 #endmeeting