fedora-qadevel
LOGS
14:00:16 <tflink> #startmeeting fedora-qadevel
14:00:16 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:16 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:00:16 <tflink> #topic roll call
14:00:23 * mkrizek is here
14:00:29 <tflink> who all's here for the meeting?
14:00:56 * jskladan is here
14:01:25 * lbrabec is here
14:01:29 <tflink> #chair mkrizek jskladan
14:01:29 <zodbot> Current chairs: jskladan mkrizek tflink
14:01:56 * kparal is here
14:02:43 * garretraziel is here
14:02:52 <tflink> roshi: you around?
14:03:24 * tflink needs help with his kamehameha
14:03:30 * roshi is
14:03:36 <tflink> anyhow, let's get this party started
14:03:38 <roshi> sorry I'm late :)
14:03:46 <tflink> #topic Announcements and Information
14:04:00 <tflink> #info libtaskotron documentation improvements -- kparal
14:04:08 <tflink> any other announcements/information?
14:04:37 <mkrizek> #info libtaskotron support for ansible task to be posted for review/discussion early this week - mkrizek
14:05:29 <tflink> any comments/questions?
14:06:03 <roshi> #info roshi working on getting ansible tasks running against docker containers
14:06:17 <tflink> roshi: do you think that'll be ready for review today?
14:07:18 <roshi> it's looking like it
14:07:22 <tflink> cool
14:07:32 <tflink> looking forward to seeing both reviews
14:07:37 <roshi> just trying to get this gzip-dist-git run_tests.yml to run
14:07:51 <roshi> keeps complaining about libselinux-python not eing installed... :/
14:08:08 <tflink> is docker selinux aware?
14:08:18 * tflink feels like he should know this
14:08:46 <roshi> I think it depends on the container?
14:08:54 <tflink> makes sense
14:08:57 <tflink> anyways, there are bunch of things on the agenda today, moving on
14:09:04 <tflink> #topic F27
14:09:30 <tflink> This is mostly a heads up to re-iterate the changes which are currently planned to land during F27
14:09:41 <tflink> 1. modularity
14:10:10 <tflink> 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 <tflink> 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 <tflink> the big potential is the assumptions we make about dist-git and builds that will go away when arbitrary branches lands
14:12:26 <tflink> the other big one is CI. the CI pipeline is supposed to land as a PoC in November
14:12:53 <tflink> I'm not sure how much it'll affect us directly other than some support/coordination work
14:13:19 <tflink> that's most of the big things I'm aware of right now
14:13:25 <tflink> most/all
14:13:40 <tflink> any question/comments?
14:14:00 <jskladan> nope
14:14:02 <mkrizek> none here
14:14:10 <tflink> k, moving on then
14:14:17 <tflink> #topic working with CI folks
14:14:55 <tflink> 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 <tflink> last week, I mean
14:15:57 <tflink> 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 <tflink> 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 <jskladan> what were those?
14:16:55 <tflink> sending requests to variable urls
14:17:46 <tflink> 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 <tflink> unless I'm missing something, we'd have to write a custom plugin to make jenkins work with the new execdb
14:18:38 <tflink> that or find one that I didn't find when I was looking last week
14:19:15 <jskladan> 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 <tflink> I'm not sure that would even work all that well
14:19:38 <jskladan> 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 <jskladan> let's see how it goes
14:19:58 <tflink> just getting per-build variables into the request-posting plugins is a challenge
14:20:23 <tflink> but it'd be worth chatting with someone who knows more about jenkins before writing stuff off
14:20:32 <jskladan> OK, that's beginning to sound like a nice steaming pile...
14:21:01 * tflink shrugs
14:21:05 <tflink> we'll figure it out
14:21:09 <jskladan> 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 <tflink> IIRC, they were happy with resultsdb as-is if they end up using it
14:22:37 <tflink> 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 <tflink> any questions/comments?
14:23:27 <jskladan> not right now
14:23:51 <tflink> ok, moving on
14:24:07 <tflink> this feels like it's turning into a brain dump instead of a meeting :)
14:24:13 <jskladan> :D
14:24:17 <tflink> anyhow, moving on
14:24:34 <tflink> #topic Future Taskotron Architecture
14:24:46 <tflink> this is more about longer-term things before getting into the libtaskotron splitting topic
14:25:26 <tflink> 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 <tflink> 1. OpenShift
14:25:50 <tflink> the stg openshift was pretty much working at the end of last week
14:26:32 <roshi> as in we run taskotron in openshift?
14:26:38 <kparal> would we get rid of minion spawning and somebody else would handle that?
14:26:40 <tflink> I'm definitely interested in being a guinea pig for that production deployment assuming we don't find huge architecture incompatibilities
14:26:48 <tflink> kparal: somewhat
14:26:52 <kparal> \o/
14:26:54 <tflink> but you're getting ahead of me a bit
14:27:19 <tflink> my big interests are more rapid and frequent deployment
14:27:37 <tflink> and no (or at least fewer) pet deployments
14:27:48 <tflink> not that we have that many as it is :)
14:28:02 <tflink> the next thing is openstack
14:28:25 <tflink> 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 <tflink> 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 <tflink> 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 <jskladan> 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 <jskladan> ah /me is a slow one to write :D
14:30:32 <tflink> no worries
14:30:56 <tflink> 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 <tflink> any questions or comments?
14:31:36 <tflink> I'm not sure what the timeline on this would be, exactly
14:31:55 <kparal> tomorrow, by any chance?
14:32:17 <garretraziel> yesterday?
14:32:17 <tflink> 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 <roshi> lol
14:32:39 <roshi> what 3 bits?
14:32:40 <tflink> :)
14:32:52 <tflink> roshi: that's the next topic
14:33:11 <tflink> the last thing (that I almost forgot) is about some other infra changes that'll be coming before too long
14:33:34 <tflink> 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 <tflink> 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 <tflink> there's also a desire to see it work with BDR (https://www.2ndquadrant.com/en/resources/bdr/)
14:34:45 <mkrizek> tflink: does that mean infra is going to maintain resultsdb?
14:34:59 <tflink> mkrizek: the infra bits, not the code bits
14:35:08 <mkrizek> yeah, that's what I meant
14:35:09 <mkrizek> cool
14:35:35 <tflink> 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 <jskladan> 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 <tflink> 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 <tflink> yeah but it would give us a few important things
14:36:52 <tflink> hot backups, HA and the potential for more scalability
14:36:54 <jskladan> sure, I'm not at all disputing that
14:37:10 <tflink> 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 <jskladan> but I'll seriously need to look into some stuff before we hit the proverbial "Go" button :)
14:37:32 <tflink> yep
14:38:02 <tflink> any comments/questions about all that?
14:38:22 <jskladan> not now, especially if that's not a priority now
14:38:54 <tflink> getting execdb to work for the ci folks and the next bit about ansible and splitting libtaskotron are the current priorities
14:39:15 <tflink> ok, moving on to that question :)
14:39:32 <tflink> #topic Ansible, Test Invocation and Splitting libtaskotron
14:40:13 <tflink> for some background, there was a proposal to have a standard "interface" through which tests are started
14:40:14 <tflink> https://fedoraproject.org/wiki/Changes/InvokingTestsAnsible
14:40:40 <tflink> 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 <tflink> mkrizek has been working on a patch to remove formulas from libtaskotron and move all execution of tests over to ansible
14:41:36 <tflink> this gives us a couple of things:
14:41:42 <tflink> 1. less requirement for custom images
14:41:45 <mkrizek> tflink: how's directives to ansible modules work going?
14:41:49 <tflink> 2. no nested runner BS
14:42:02 <tflink> 3. Less code to maintain
14:42:11 <tflink> 4. less documentation to write and maintain
14:42:42 <tflink> 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 <tflink> 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 <tflink> 1. taskotron-runner - the current executor, responsible for target spawning, kicking off ansible
14:44:24 <tflink> 2. libtaskotron - pure python bits (i.e. koji_utils, bodhi_utils, rpm_utils)
14:44:56 <tflink> 3. fedora-testing-ansible-modules - the custom ansible modules which help folks test fedora (i.e. koji, bodhi)
14:45:18 <tflink> thoughts?
14:45:59 <kparal> the ansible modules will depend on libtaskotron then, right?
14:46:20 <tflink> yep
14:46:43 <jskladan> 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 <tflink> yeah, I suspect that we'll be trading our current pain points for some new ones
14:47:28 <kparal> I don't have any objections either. we'll see what obstacles we discover along the way
14:47:32 <tflink> less pain overall but there'll be issues :)
14:48:40 <roshi> we'll see what it ends up like
14:49:03 <tflink> just put it all in the cloud - docker will make things better :)
14:49:14 <roshi> oh yeah
14:49:19 <roshi> no pain at all, there
14:49:33 <tflink> mostly because roshi is the "cloud guy" in these parts and it'd be _his_ problem :-D
14:49:39 <roshi> lol
14:50:00 <tflink> any other comments, questions, concerns etc. ?
14:50:50 * tflink takes that as a no
14:50:54 <tflink> which moves us on to ...
14:50:57 <tflink> #topic Open Floor
14:51:23 <tflink> any other topics that folks would like to bring up?
14:51:31 * roshi has nothing at this point
14:51:42 <kparal> I've been spending some time improving docs in the last days
14:51:53 <kparal> I tried to avoid touching formula etc topics, since that's going away
14:52:01 <kparal> anything else in particular I should avoid?
14:52:25 <tflink> I can't think of anything in particular, no
14:52:34 <tflink> but it may all be changing, I suppose :)
14:52:36 <kparal> e.g. I assume directive docs will still be useful, just move to a different place
14:52:42 <tflink> yeah
14:53:14 <tflink> we may end up with way fewer directives/modules, too
14:53:23 <kparal> 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 <tflink> agreed
14:53:41 <kparal> we have some of that as part of libtaskotron, and most of it missing. we should have it separate, I think
14:54:37 <kparal> 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 <tflink> 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 <tflink> either that or wiki
14:54:59 <kparal> ok
14:56:37 <tflink> I think that roshi started on something similar that may help
14:56:47 <tflink> roshi: do you have a link to the stuff you wrote up?
14:57:59 <tflink> anyhow, we're pretty much out of time
14:58:13 <roshi> the taskotron overview?
14:58:18 <tflink> documentation +eleventymillion, though
14:58:20 <tflink> yeah
14:58:24 <roshi> jas
14:58:39 <roshi> https://fedoraproject.org/wiki/User:Roshi/QA/Taskotron_Overview
14:58:41 <tflink> if there's nothing else, I'll close out the meeting in a minute or two
14:58:49 <kparal> thanks, will look
14:59:52 <roshi> patches welcome if I missed details or got something wrong
15:00:21 <tflink> ok, thanks for coming, everyone
15:00:25 * tflink will send out minutes shortly
15:00:28 <tflink> #endmeeting