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