15:01:25 <tflink> #startmeeting fedora-qadevel 15:01:25 <zodbot> Meeting started Wed Feb 15 15:01:25 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:25 <zodbot> The meeting name has been set to 'fedora-qadevel' 15:01:30 <tflink> #meetingname fedora-qadevel 15:01:30 <zodbot> The meeting name has been set to 'fedora-qadevel' 15:01:37 <tflink> #topic roll call 15:01:40 <linuxmodder> .fas linuxmodder 15:01:42 * pschindl_ is here 15:01:42 * mkrizek is here 15:01:51 <tflink> #chair jskladan_znc kparal mkrizek lbrabec 15:01:51 <zodbot> Current chairs: jskladan_znc kparal lbrabec mkrizek tflink 15:01:51 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org> 15:01:59 <tflink> #chair linuxmodder 15:01:59 <zodbot> Current chairs: jskladan_znc kparal lbrabec linuxmodder mkrizek tflink 15:02:13 * kparal is still here 15:02:25 <mkrizek> #chair garretraziel 15:02:25 <zodbot> Current chairs: garretraziel jskladan_znc kparal lbrabec linuxmodder mkrizek tflink 15:02:27 * jskladan_znc left 15:02:51 * garretraziel was here five minutes ago 15:03:13 <linuxmodder> tflink, please unchair me ( Im in qa but here mostly for educational reasons 15:03:53 <tflink> how does one unchair? 15:04:16 <tflink> #unchair 15:04:16 <zodbot> Current chairs: garretraziel jskladan_znc kparal lbrabec linuxmodder mkrizek tflink 15:04:20 <tflink> #unchair linuxmodder 15:04:20 <zodbot> Current chairs: garretraziel jskladan_znc kparal lbrabec mkrizek tflink 15:04:28 <tflink> i guess that makes sense 15:05:01 <Southern_Gentlem> me 15:06:29 <tflink> https://public.etherpad-mozilla.org/p/20170215-fedora-qadevel 15:06:39 * tflink will translate that to wiki later 15:06:46 <tflink> wasn't thinking when i wrote that up 15:06:54 <tflink> so, getting started 15:07:10 <tflink> #topic Issues 15:07:18 <tflink> #undo 15:07:18 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x366f5910> 15:07:32 <tflink> #topic Issues - VMs not being cleaned up (T905) 15:07:44 <tflink> #link https://phab.qa.fedoraproject.org/T905 15:08:24 <tflink> sigh, not sure this is what we want to start with 15:08:36 * tflink blames 5am meetings for lack of coherency 15:08:54 <tflink> #undo 15:08:54 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x35c52890> 15:08:56 <tflink> #undo 15:08:56 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x39112990> 15:09:25 <tflink> now that I've confused everyone ... 15:09:47 <tflink> jskladan: were there specific things you wanted to cover? 15:09:57 <tflink> mostly project priority? 15:10:16 <jskladan> yes, mostly project priority 15:10:25 <jskladan> we have some changes to be done on ExecDB and Trigger 15:10:39 <jskladan> I have already put together a document covering my thoughts on ExecDB 15:10:49 <tflink> #topic Projects and Priorities 15:10:52 <jskladan> (please read and comment, if you did not already) 15:11:04 <jskladan> and I'm now putting together a thing on Trigger 15:11:22 <jskladan> #link https://docs.google.com/a/redhat.com/document/d/1spU0tK7pb4NBWFgY535Nawm1O69z3R928K8os6AAIfg/edit?usp=sharing 15:11:31 <jskladan> (keep in mind that this is WIP) 15:11:43 <garretraziel> also it's internal document 15:11:56 <tflink> The three projects I can think of right now are: execdb rework, CI for taskotron and a frontend for trigger 15:12:18 <tflink> yay internal tooling! 15:12:35 <jskladan> I'd say that trigger being able to work with Jenkins is a bigger priority than the web frontend 15:12:39 <jskladan> but yeah 15:12:49 * tflink was grouping that in with the execdb rework 15:12:55 <tflink> should have been more explicit 15:12:55 <jskladan> OK, that makes sense then 15:14:01 <tflink> jskladan: what are you missing for the execdb and trigger rework to be less dependent on jenkins? 15:14:04 <tflink> s/jenkins/buildbot 15:14:20 <tflink> are there any unresolved issues from the document you sent out? 15:14:20 <jskladan> execdb needs complete rehaul, basically 15:14:26 <jskladan> there is no way around it 15:14:33 <jskladan> but it is covered in the document 15:14:41 <tflink> yeah, I was wondering what was needed before that can start 15:14:47 <jskladan> ah, ok 15:15:13 <jskladan> if we agree on the proposal, then work on that can begin 15:15:20 <jskladan> there is nothing blocking it as far as I know 15:15:44 <jskladan> with trigger, adding jenknins support *should* be as easy as adding a new Runner class 15:15:49 <tflink> of the folks who can access the doc, any objections to the contents? 15:16:13 <tflink> jskladan: can you translate that doc to a wiki page or something that can be shared outside of RH? 15:16:22 <jskladan> ad docs - as kparal pointed out, I'll probably re-share those via my personal gdoc 15:16:22 * kparal read execdb doc so far, looks reasonable 15:16:32 <jskladan> so people outside rh can comment 15:16:39 <jskladan> but it can be boilded down to wiki as well 15:16:45 <jskladan> wahtever 15:16:47 * tflink also did not realize that rh google docs can't be public 15:17:00 * mkrizek also read execdb doc, looks good 15:17:14 * jskladan likes the way it allows for comments, but for the "finished proposal" I can easily do wiki page 15:17:37 <jskladan> the trigger doc will be shared from my personal gdoc, so its RH-account-agnostic 15:17:44 <tflink> sounds good 15:17:47 <jskladan> cool 15:18:23 <jskladan> mkrizek, garretraziel: do you think you can start working on the trigger-jenkins runner (+ the related jenkins bits) soon-ish? 15:18:28 <tflink> I'd say get the doc available for non-rh folks to comment on and get started on it soon 15:18:30 <jskladan> I see this as the biggest priority right now 15:18:39 <mkrizek> jskladan: I have already started 15:19:17 <jskladan> mkrizek: cool, discussed some (maybe non-relevant) details with garretraziel today, hope he'll share it in person with you 15:19:38 <tflink> jskladan: what about re-running jobs? is that something which will be in excdb, even if not initially? 15:20:00 <jskladan> for job re-runnning, we need trigger to start storing the relevant data 15:20:15 <jskladan> I'm putting together some thoughts on that in the gdoc I posted earlier 15:20:19 <tflink> ok, I'm not picky about where the re-triggering lives 15:20:27 <jskladan> and then trigger will need an API so it can be done 15:20:42 <jskladan> ExecDB should then have a "re-run" button associated with the job 15:20:57 <jskladan> telling trigger to "just run it again, will ya, sweetie?" 15:21:10 <tflink> thoughts on time needed for something that's demo-able vs. done enough for deployment? 15:21:10 <jskladan> and from there forward it's just a regular Taskotron job 15:21:21 <tflink> jskladan: sounds good to me 15:21:47 <jskladan> I firmly believe I can sort out the necessary-data-logging next week 15:21:56 <jskladan> not sure about the api, now 15:22:35 <jskladan> but some demo-able shitty-piece-of-code that just accepts the request and runs the command-line trigger tool with the right parameters 15:22:41 <jskladan> can IMO be done in a day or two 15:23:34 <garretraziel> jskladan: mkrizek started working on it and he was planning to do things just as we discussed 15:23:54 <jskladan> (and by "a day or two" I mean "a day or two after the trigger thing is done") 15:24:00 <jskladan> garretraziel: awesome 15:24:25 <tflink> jskladan: not sure of the api for what? trigger so that it can accept rerun requests? 15:24:49 <jskladan> yes that 15:25:09 <jskladan> RESTful api, that you can hit to say "hey, rerun a job with this UUID" 15:25:44 <tflink> it sounds like either you or mkrizek are working on a design for that? 15:25:45 <jskladan> as trigger is far from web-app now, I'm not sure how much of work would that mean, but for something demo-able, we don't really care that the "api" and the "actual trigger" are two separate things 15:25:57 <jskladan> tflink: AFAIK I am 15:26:02 <tflink> #action jskladan to share execdb document in a way that everyone can read 15:26:16 <jskladan> mkrizek is working on "let's be able to run stuff in jenkins" IMO 15:26:16 <tflink> ok, wasn't sure who was working on it 15:26:20 <tflink> ah 15:26:34 <tflink> do we have tickets for this stuff? I know I've been slow about filing them 15:27:42 <jskladan> nope, I'll start filling tickets once I'm done with the spec-documents 15:27:51 <jskladan> (or if there are any volunteers.... kparal? :)) 15:27:59 <tflink> mkrizek: is there a ticket for the jenkins triggering work? 15:28:27 <mkrizek> tflink: it isn't, I was going to create it but got distracted, can do it later though 15:28:27 * kparal is not here, was never here 15:28:37 <tflink> mkrizek: thanks 15:29:24 <tflink> so, to sum up and make sure that there is understanding: 15:29:56 <tflink> the execdb doc looks good so far, jskladan will start filing tickets for it and working on it soon after posting a more public document 15:30:23 <tflink> the trigger API for re-run stuff will be proposed soon, worked on after execdb's rewrite is more done 15:30:45 <tflink> mkrizek is working on the ability to trigger jenkins in addition to buildbot from taskotron-trigger 15:31:03 <jskladan> I'd say that the execdb rewrite is up for grabs - does not need to be me doing that - but if nobody wants to, I'll do it for sure 15:31:06 <tflink> do we know if any plugins will be needed to get jenkins to post status information like we need it to? 15:31:13 <tflink> makes sense 15:31:48 <jskladan> tflink: the way I see it, the status info is a http-call - could be as easy as adding some CURL calls into the middle of the steps 15:32:09 <tflink> yeah, just wasn't sure how hard it would be to make jenkins do that 15:32:09 <jskladan> but if there is a more elegant solution... 15:32:13 <mkrizek> yeah, should be done the same way as buildbot steps - any command 15:32:20 <mkrizek> *could 15:32:31 <jskladan> mkrizek: cool, I'd start with that, and we can make it more elegant later on 15:32:41 <mkrizek> agreed 15:32:41 <tflink> just with more targeted updates in status intead of the firehose coming out of buildbot :) 15:32:51 <jskladan> yes 15:33:11 <tflink> any comments, questions, concerns about this? 15:33:15 * jskladan wants to burn that code handling buildbot's push notifications into ground 15:33:32 <tflink> :) 15:33:58 <tflink> out of curiosity, is the frontend stuff that you guys worked on around devconf abstract enough to be used in these new frontends? 15:34:15 * tflink hasn't looked at the html/css yet 15:35:45 * tflink hopes so, it'd be nice to have more uniform looking UIs going forward 15:35:56 <jskladan> well, it's a bag full of cats 15:36:01 <jskladan> so... no :D 15:36:07 <tflink> ok 15:36:11 * tflink was hoping :) 15:36:17 <jskladan> I'd like to put some work into making it a bit more universal 15:36:28 <tflink> anyhow, moving on as we're 35 minutes in and one topic down 15:36:35 <jskladan> but now it is just tons of css edits repeating in all the places :D 15:36:46 <tflink> sounds lovely :) 15:37:21 <tflink> #topic Chronic Issues (T905, T906) 15:38:04 <tflink> T905 is something that can be scripted away for the short term, so I'm not so worried about it 15:38:20 <tflink> T906, on the other hand, I don't think has an easy workaround 15:38:43 <tflink> T878 is a possible fix 15:38:44 <tflink> https://phab.qa.fedoraproject.org/T878 15:38:50 <jskladan> is not "kill depcheck, use rpmdeplint" a nice workaround for T906? 15:38:58 * kparal believes so 15:39:05 <mkrizek> +1 15:39:11 <jskladan> +gazillion 15:39:20 <garretraziel> +1 for dropping depcheck and using rpmdeplint instead 15:39:28 <tflink> ok, can we do that soon enough w/ coordinating with bodhi folks? 15:39:39 <kparal> we of course need to decide whether we want to keep the name or not, and similar bikeshedding 15:39:47 <jskladan> just name it depcheck...\ 15:40:13 <jskladan> no changes in bodhi needed, depcheck dies, kittens are saved, jesus loves you... 15:40:16 <jskladan> good stuff 15:40:20 * tflink is all for getting rid of depcheck so we don't have to worry about it but wonders if it would be more efficient to fix the python-libsolv issue for now and not rush into these changes 15:40:25 <kparal> I'd not like to see people googling for depcheck and finding our old implementations and then trying to run it locally to reproduce issues 15:41:02 <kparal> I'll have a look at the libsolv issue 15:41:27 <tflink> kparal: thanks 15:41:44 <tflink> AFAIK, this is happening for all the depcheck runs on all the fedoras we're running 15:41:58 <kparal> at least it's deterministic :) 15:42:10 <tflink> yeah, it was that last libsolv update 15:43:18 <tflink> kparal: can you add findings to T906 when you've had a chance to look into it more? 15:43:24 <kparal> will do 15:43:46 <tflink> if possible, I'd prefer to change the result names to dist.rpmdeplint 15:44:02 <tflink> that way it isn't confused with any of our previous incarnations or the releng depcheck tool 15:44:38 <tflink> we do need to speak to bowlofeggs about any changes to bodhi, though 15:44:43 <mkrizek> I'd prefer dist.rpmdeplint.sat - since there are more checks that could be run within the rpmdeplint tool 15:45:15 <kparal> (naming is discussed in https://phab.qa.fedoraproject.org/T878 ) 15:45:29 <kparal> we can continue there 15:45:35 <mkrizek> sure 15:45:41 * tflink dislikes calling everything sat and pretending that it's a specific thing instead of a class of problems but that ship sailed a long time ago 15:46:07 <tflink> anyhow, discussion to be continued in T878 15:46:12 <tflink> and T906 15:46:16 <tflink> anything else to add? 15:46:21 <mkrizek> not here 15:46:41 <jskladan> nope 15:46:52 <tflink> #topic Update Resultsdb in Prod 15:47:17 <tflink> the newest resultsdb has been running in dev and stg - any reason not to update prod at the next opportunity? 15:47:35 <jskladan> tflink: if it's not misbehaving, I don't see any reason to wait 15:47:46 <kparal> yes, let's fix the frontend search asap 15:47:49 * tflink couldn't think of a reason not to but wanted to ask 15:48:27 <mkrizek> +1 for update 15:48:55 <tflink> #topic meta-CI for taskotron 15:49:05 * tflink is still a bit behind on this one 15:49:16 <tflink> it looks like the self-tests are pretty much ready now? 15:49:21 <tflink> or at least a base for them? 15:49:42 <kparal> it's magic and it works, kparal can attest 15:49:47 <kparal> jskladan++ 15:49:48 <zodbot> kparal: Karma for jskladan changed to 2 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:49:54 <tflink> cool 15:50:04 <jskladan> yup, the framework is ready (and working), now we need to actually do some sensible testing. The initial version spins up a job, and checks whether exedb/resutlsdb data appears 15:50:05 * kparal finally installed docker 15:50:24 <tflink> I assume that the next step is to get it running when we need it to run 15:50:30 <jskladan> yup 15:50:51 <jskladan> IIRC the pagure-git-commit consumer is in trigger's devleop already 15:51:03 <tflink> cool 15:51:17 <tflink> it'd be great to get it running on proposed change as well but that can happen later 15:51:33 <jskladan> the actual trigger rules will need to be put together for that task, but it is just a minor issue 15:51:39 <jskladan> and I can do that tomorrow 15:51:40 <tflink> do we want to do notifications in any different way than relying on FMN? 15:51:57 <jskladan> tflink: you mean for the results of the CI? 15:52:01 <tflink> I can't think of a better option for the short term, even if there can be quite a bit of lag 15:52:02 <tflink> yeah 15:52:27 <jskladan> short term, I'd do FMN, later on, we could have some tool that puts comments in pagure based on new results in resutlsdb 15:52:30 <jskladan> or stuff like that 15:52:33 <jskladan> IDK 15:52:46 <tflink> yeah, there's no project-agnostic API for doing that right now 15:53:00 <jskladan> I don't see it as a huge priority at this very moment 15:53:05 <tflink> agreed 15:53:07 <kparal> I'd like to hook up #fedora-qa with fmn, so that we can subscribe to important events 15:53:16 <kparal> I already asked infra folks how to do it 15:53:21 <tflink> that also sounds good 15:53:28 <tflink> anything else? 15:53:39 * tflink assumes not 15:53:49 <tflink> #topic Test Storage in Dist-GIt 15:54:34 <tflink> long story short, it's changing again 15:54:52 <jskladan> yaaay 15:54:55 * tflink is writing up a newer proposal, hoping to have it out for comment no later than next week 15:54:58 * jskladan loves me some change 15:55:42 <tflink> mostly a heads-up at this point - we haven't forgotten, the details just seem to be stuck in endless bureaucracy 15:55:49 <tflink> and moving on to ... 15:55:55 <tflink> #topic Open Floor 15:56:00 <tflink> any other topics to discuss? 15:56:09 <tflink> with the 5 minutes we have left :) 15:57:48 * tflink takes that as a no 15:57:48 <jskladan> images of cute kittens? 15:57:54 <tflink> thanks for coming, everyone! 15:58:18 <tflink> jskladan: NO! CUTENESS IS FORBIDDEN! 15:58:25 <tflink> on that note ... 15:58:31 * tflink will send out minutes shortly 15:58:34 <tflink> #endmeeting