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