14:01:16 #startmeeting fedora-qadevel 14:01:16 Meeting started Mon Jul 17 14:01:16 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:16 The meeting name has been set to 'fedora-qadevel' 14:01:16 #topic roll call 14:01:33 Yaay, such roll, many call! 14:01:35 #chair jskladan kparal garretraziel roshi 14:01:35 Current chairs: garretraziel jskladan kparal roshi tflink 14:01:37 * tenk is here* 14:01:54 * kparal is here 14:02:10 * roshi is here 14:03:04 * garretraziel is here 14:03:26 ok, let's get this party started 14:03:34 hopefully we can keep it short 14:03:41 #topic Announcements and Information 14:03:55 #info depcheck has been removed from production -- kparal and mkrizek 14:03:55 #info libtaskotron 0.4.24 built and submitted as updated (still in testing) -- kparal 14:03:55 #info task-mtf now has a pretty html overview page -- kparal and jscotka 14:03:55 #info taskotron stack now works with Jenkins in place of Buildbot -- jskladan (+jsedlak) 14:04:03 any additional items? 14:04:14 #info mkrizek has left Fedora QA 14:04:36 that's a good point 14:05:05 * jskladan Banish the traitor! Make him do all the sysadmin tasks anyway! Spanish inquisition! 14:05:18 do you think that any more formal announcement is needed? or just tell mkrizek to send folks to us and deal with it if he gets too many requests? 14:05:28 * tflink is leaning to the "deal with it if/when we need to" 14:05:36 the latter, yes 14:05:50 tflink: yea, just leave it be.. :) 14:05:59 jskladan: you're in a much better position to keelhaul the traitor than I am ... 14:06:01 :-D 14:06:26 nice torture, didn't know 14:07:22 anything else WRT announcements or general information? 14:07:29 nothing from me 14:07:34 nope 14:07:47 ok, moving on 14:08:06 #topic taskotron + Jenkins 14:08:28 jskladan: are you OK with describing a bit more what you and garretraziel did and what state it's in? 14:08:41 tflink: sure 14:08:59 so... we replaced Buildbot with Jenkins 14:09:06 \o/ 14:09:14 whee 14:09:23 most of the work was towards making sure we can report per-step into execdb 14:09:54 (this is something we want, so we can implement super-smart auto-reruns later on, for example) 14:10:15 instead of just the "job started/ended" messages that Jenkins can do with a plugin that already exists 14:10:22 were you able to get around the code duplication in the pipelines you're using? 14:10:55 this is done using the Pipeline syntax, and a wrapper function that makes the http posts 14:11:32 (note that pipeline syntax also has `post` phase where you can define `success`, `failed`, etc "callbacks", but that means duplicating the callback code for each step) 14:11:58 I wonder how many steps we will have in execdb with ansible-based tasks. probably just "1. spin up VM; 2. run task" 14:12:02 am I wrong? 14:12:23 gather results, cleanup 14:12:32 clone task git repo 14:12:36 the only changes in our current code to make it work were in execdb - added endpoint for consuming the job start/finish notifications 14:12:53 do we still do that, cloning a repo? doesn't the task do it itself? 14:12:56 AFAIK, the switch to ansible won't change much from the execution process that we're already using 14:12:58 and in trigger, adding "jenkins runner" 14:13:11 I thought so, did I miss something? 14:13:14 kparal: ad "anisble tasks" I suspect it will be exactly the same 14:13:26 we'd just be "running ansible" instead "running taskotron runtask" 14:13:32 the rest will IMO be the same 14:13:35 ok 14:13:39 or at least as much as I can say 14:13:47 ok, back to jenkins 14:14:01 The whole PoC is dockerized 14:14:13 \o/ 14:14:24 good 14:14:33 and you can try it out: just clone the `testjenkins` branch of https://pagure.io/taskotron/task-taskotron-ci repo, and run `docker-compose up --build` 14:14:51 this spins up the whole stack, and executes a job inside it 14:14:54 * kparal inserts \o/ if he sees the right buzzword, like jenkins or docker 14:15:01 jenkins is accessible at localhost:8080 (admin:admin) 14:15:09 execdb at :5003 14:15:21 all we need is openshift and that'd make BINGO! 14:15:40 (bonus points for watching execdb job detail update in real-time as the jenkins job runs) 14:15:41 jskladan: are the execdb changes public somewhere? 14:15:52 it's in the pony branch 14:16:01 together with the "new" execdb 14:16:08 cool 14:16:32 the Jenkins settins are most probably not ideal, nor complete 14:16:37 glad to hear that you were able to get that figured out - it hadn't occurred to me that pipelines could help when I looked into it 14:16:39 but sufficient for PoC 14:16:59 yeah, it sounds like we'll need quite a bit more work to get everything working "properly" enough for production 14:17:08 the most pressing issues will IMO be artifact storage (we need to have the uuid-based link, jenkins does not care for our uuid) 14:17:39 but this can be dealt with in more or less sane way, I hope 14:17:56 anyway - we won't be taking care of our own Jenkins instance hopefully 14:18:07 ideally, no 14:18:20 we still have work to do before we can use the centos ci stuff, though 14:18:26 auth, mostly 14:19:02 kparal was suggesting using Centos CI stuff, and AFAIUI there is push for Jenkins from within Red Hat, so acquiring managed Jenkins instance might as well be a piece of cake 14:19:02 that's something I wanted to ask, have we already talked to centos ci folks whether we can use their infra? 14:19:04 (lol, I know) 14:19:07 yep 14:19:24 so the major roadblock in auth? 14:19:26 *is 14:19:28 for the jenkins master and clients, anyways 14:19:29 yeah 14:19:39 auth for what 14:19:42 resultsdb doesn't have a concept of ACL 14:19:42 what exactly do we need to solve with auth? 14:19:42 ? 14:20:05 right now, it's IP based, assuming it's on the same network as the things sending it results 14:20:30 if we move our execution to the centos ci infra, the results would be reported from a different network, though a public interface 14:20:48 chmod 777 resultsdb? 14:21:07 I guess that won't fly :) 14:21:14 you guess correctly :-P 14:21:23 like it mattered... 14:21:24 :D 14:21:29 we build Fedora on *trust*! 14:21:35 there is a partial patch pending for resultsdb 14:21:50 but honestly - how often did anybody intentionally screw up the matrices? 14:21:51 from factory 2.0 folks? 14:22:01 a note: there is a patch from puiterwijk in Phab, that adds oauth-based auth 14:22:20 ok 14:22:23 but don't really understand it, and I'm not at all sure how to test it/put it together for real 14:22:53 I think it'll involve reaching out to puiterwijk for some certs in the dev ipsilon instance 14:23:04 that's how I got phab auth working, anyways 14:23:11 jskladan: I can help with getting you setup for testing etc when you want 14:23:30 tflink: I'd prefer not using cert based auth, but to use the patch I provided :) 14:23:45 * tflink hasn't looked closely at the patch 14:24:20 puiterwijk: tflink: awesome. As I said, I'm a clean slate WRT auth 14:24:20 puiterwijk: wouldn't it still require a cert to be able to auth against ipsilon? 14:24:33 * tflink is taking this into a rat hole 14:24:43 tflink: no, it needs a client secret 14:24:46 client secret != cert. 14:24:52 But yes, you do need something provided by infra 14:24:58 ah, I'm just being sloppy with my terminology 14:25:06 Righ 14:25:09 Right even 14:25:22 Anyway, feel free to ping me whenever and I can help people set up their dev instances 14:25:28 thanks 14:25:41 My patch has been there long enough, I'm sure people can find it :D 14:26:46 anything else on this? 14:26:56 tflink: nothing on my end 14:26:57 we drifted quite a bit there at the end 14:27:31 ok, moving on 14:27:51 #topic Fedora Atomic Host CI and ResultsDB 14:27:56 this should be quick 14:28:16 I've gotten a request to help with a part of the CI effort for FAH 14:28:52 still lacking details but hopefully it won't require any major changes to resultsdb 14:29:11 any details yet? 14:29:23 as I understand it, the request is to help getting information from the CI pipeline into resultsdb in the form of a fedmsg listener 14:29:42 jskladan: not enough to do much work with yet, no 14:29:52 tflink: is this what originally was supposed to be the execdb changes, or something completely different? 14:30:04 jskladan: not sure, to be honest 14:30:18 * tflink is hoping to get more details today 14:30:27 ok, no worries then, feel free to redirect any RFEs my way 14:31:01 it sounds like there are some questions around how to store certain data in resultsdb, so I suspect that I'll be looping you in on the work once its more figured out 14:31:10 any questions or comments? 14:31:58 not yet 14:32:03 nope 14:32:07 ok, moving on 14:32:12 #topic Tasking 14:32:28 I'm planning to work on the atomic CI stuff 14:32:45 jskladan: is there more to do with the Jenkins PoC this week? 14:32:56 nope, that is done from my PoW 14:33:17 jskladan: what are you planning to work on this week? 14:33:29 I'll try to get the auth stuff integrated 14:33:36 ok, that's what I was going to suggest :) 14:33:43 and I'll bother josef with some admin requests 14:33:53 kparal: are you looking for stuff to do? 14:33:56 and kparal wants some shady imagefactory bussines to take part 14:34:12 * tflink really wants that imagefactory stuff to DIAF 14:34:17 I plan to look at the ansiblize branch and move it forward 14:34:23 sounds good 14:34:37 lbrabec has been already looking at it as well 14:34:42 cool 14:34:51 sadly, I feel like even mentioning imagefactory in a sentence means a wasted week of time 14:35:11 tflink: I agree, that needs to DIAF ASAP 14:35:26 I'd love to switch over to openstack's DIB 14:35:32 but that'll take time :( 14:35:58 assuming it'll end up working better than imagefactory, anyways 14:36:00 but I digress 14:36:00 if we get access to Centos CI, will we also be able to use their prebuilt images? 14:36:13 they have prebuilt fedora images? 14:36:22 I assume they'll need the same images we do 14:36:29 since they want to test fedora atomic 14:36:42 AFAIK, the only thing that they're looking at is Fedora atomic host but I could be wrong 14:37:13 so we might need to build the images for some time still 14:37:23 it's possible, yeah 14:37:44 depends on who's doing what CI where - if you get answers to that, I'd love to hear them 14:37:46 * roshi isn't sure about the Centos side of things, even on the Atomic bits 14:37:57 I know there's involvement, but don't know the extent of it 14:38:52 anyone else looking for a task or tasks? 14:39:41 * tflink takes silence as a "no" 14:39:50 #topic Open Floor 14:39:57 any other topics that folks want to bring up? 14:40:21 nothing here 14:40:28 * roshi has nothing 14:40:55 * tflink lights the non-deterministic fuse 14:42:05 thanks for coming, everyone 14:42:10 * tflink will send out minutes shortly 14:42:13 #endmeeting