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