14:01:50 <tflink> #startmeeting fedora-qadevel
14:01:50 <zodbot> Meeting started Mon May  2 14:01:50 2016 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:50 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:50 <tflink> #meetingname fedora-qadevel
14:01:50 <tflink> #topic Roll Call
14:01:50 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:56 * kparal is here
14:01:57 * mkrizek 
14:02:06 <tflink> #chair mkrizek kparal jskladan garretraziel
14:02:06 <zodbot> Current chairs: garretraziel jskladan kparal mkrizek tflink
14:02:16 * jskladan yay, a chair!
14:02:27 * garretraziel is here
14:02:46 * tflink put the wrong wiki link in the email again
14:02:47 <tflink> :(
14:02:56 <tflink> https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20160502-fedoraqadevel/
14:03:22 <jskladan> should we repost?
14:03:24 <linuxmodder> .hello linuxmodder
14:03:25 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
14:03:28 <tflink> nah
14:03:32 * linuxmodder here but also in another mtg
14:04:44 <tflink> ok, let's get this party started :)
14:04:48 <tflink> linuxmodder: no worries
14:05:31 <tflink> #topic Announcements and Information
14:05:39 <tflink> #info new blockerbugs deployed to stg - tflink
14:05:40 <tflink> #info imagefactory builds F23/24, F25 builds fail, but that is not a problem in imgfac - jskladan
14:05:50 <tflink> anyone have stuff to add, comments, questions?
14:07:57 * tflink takes that as a no
14:08:10 <tflink> sorry, somewhat distracted today - trying to get someone up to speed on fedora testing
14:08:22 <tflink> moving on to
14:08:29 * kparal on a call
14:08:30 <tflink> #topic Docker Testing
14:09:19 <tflink> not much to say here, just wanted to make sure I had understood everything from last week and was being clear about what's needed
14:09:43 <tflink> one thing that we are expected to do is come up with "here is how you should write automated tests for docker"
14:10:45 <linuxmodder> tflink,  quick link or  overview pls  missed last week
14:11:59 <tflink> loking
14:12:01 <tflink> looking
14:12:41 <linuxmodder> don't  delay on that  I can doa pm post mtg if its not handy :)
14:12:56 <tflink> yeah, I'll have to look for it, sorry
14:13:03 <linuxmodder> np
14:14:12 <tflink> other than me, are there any folks who think we should have a "generic" runner?
14:14:47 <linuxmodder> as in docker-run ?
14:14:53 <linuxmodder> if so yes me too
14:15:39 <tflink> no, as in a "framework" to write tests in
14:15:50 <tflink> based off of py.test, unittest etc.
14:16:17 <linuxmodder> ah -- would be nice  but not sure it  'required'
14:16:41 <tflink> is that a "no" or is everyone paying attention to other stuff?
14:16:50 <jskladan> linuxmodder: not sure what you mean by "as in docker-run", TBH
14:16:50 <jskladan> tflink: I'm not opposed to a generic runner as such, I just do not see the merit of unittest tool being used for "not unittesting"
14:17:50 <tflink> I'm changing my argument for now, at least - there are much bigger fish to fry at the moment. if we can come up with a better way for folks to write docker tests without something like py.test, that's fine by me
14:18:26 <tflink> jskladan: AFAIK, py.test is used for plenty of things outside of what we might think of as the stereotypical unittest case
14:18:36 <tflink> but that's a pretty weak argument :)
14:18:47 <jskladan> :)
14:20:17 <tflink> if we aren't going to use something like pytest or unittest, how do we want to approach writing tests for docker images?
14:20:26 <jskladan> I suspect most of the docker tests will be bash, as it is the easiest way to interact with docker
14:21:56 <tflink> I'd like to be a bit more specific than bash
14:22:12 <tflink> at the very least, several well-documented examples
14:23:06 * jskladan *shrugs* the thing is, that I feel like we should talk to the actual people, that will want to test docker
14:23:41 <jskladan> although I understand that having examples is a good thing, talking to the test devs seems like the obvious idea
14:23:49 <tflink> yeah, I'm just not sure who those people are
14:24:12 <jskladan> since lately, it feels like we are trying to guess "what will be going on"
14:24:15 <tflink> I've not really gotten many concrete answers to the question of "how do we test docker images?" much less "what will you want to tests?"
14:24:21 <tflink> oh, we are
14:24:36 <tflink> answers are not easy to come by
14:24:41 <jskladan> which is, from my POW, quite a stupid place to be at
14:25:05 <jskladan> like I'm supposed to tell the kernel dev how to test the kernel
14:25:06 * tflink is all for suggestions that allow us to meet our commitments
14:25:10 <jskladan> what do I know..
14:25:19 <tflink> note that I'm not arguing with you :)
14:25:50 <jskladan> I understand, but if there is a pressure on us, then shouldn't we put the pressure back?
14:26:08 <tflink> it is a bit crazy but I don't have any better ideas ATM and there's not really any wiggle room in supporting docker image automation in F25
14:26:23 <tflink> in an ideal world, yeah
14:26:32 <tflink> but I'm not even sure who to put the pressure back on
14:26:39 <jskladan> well, who is pressuring us?
14:26:54 <tflink> people who I'm not going to pressure back because they aren't the source of things
14:27:38 <jskladan> and I guess they do not know either...
14:27:49 * jskladan is feeling a bit like an Alice in Wonderland
14:28:05 <tflink> join the party :)
14:28:49 <tflink> my short term goal is mostly to get the box checked without putting too much effort into things that aren't definitely needed for "docker automation"
14:28:50 <jskladan> ok, let's move on.... To be honest, if saying yes to (from my pow bad) unittest will make at least somebody happy, I do not really feel like I should fight it any more
14:29:16 <tflink> I'm not fighting for unittest, quite the opposite at the moment
14:29:32 <tflink> just wanted to be sure that nobody else thought it was a requirement before moving on
14:29:41 <tflink> yes, I did change my mind for now :)
14:30:00 <tflink> but we seem to have ended up in the weeds a bit
14:30:59 <jskladan> ok, so to sum it up - if we just need to come up with something, I'm not against having (e.g.) two examples, where one uses bash and return code(s) to test stuff, and the other just blatantly steals some of the tests now written for tunir
14:31:00 <kparal> sorry, back from a call, reads back
14:31:06 <jskladan> and "let them decide"
14:31:09 <jskladan> how about that?
14:31:14 <tflink> that sounds good to me
14:32:02 <tflink> it may be worth using tunir for that example
14:32:24 <tflink> I've been told that it doesn't require spinning up its own stuff and in theory, it should work fine for docker
14:32:39 <jskladan> well, we don't need to use tunir as such in any way
14:32:46 <jskladan> we can just plain run some of the tests
14:32:47 * tflink will continue to try figuring this out with the cloud folks
14:33:00 * jskladan wishes lbrabes was here, as he has some PoCs
14:33:12 <tflink> if the tests are unadulterated, I'm fine with that so long as we don't put much effort into it
14:33:29 <tflink> .fire lbrabec for not showing up for the meeting
14:33:29 <zodbot> adamw fires lbrabec for not showing up for the meeting
14:34:09 <jskladan> from what I've seen, it was really simple, and the tests (I guess ran by tunir) do not actually use anything from it
14:34:16 <jskladan> so we are good to go as a runner there
14:34:29 <tflink> yeah, I think most of the tunir code is for setting up vms, etc.
14:34:33 <jskladan> which is the way it's done in taskotron *insert eagles and national anthems*
14:35:11 <tflink> jskladan: you're sounding somewhat 'merican and I'm concerned
14:35:18 <tflink> american != 'merican
14:35:51 <tflink> anyhow, it sounds like we have a decent plan for now
14:35:55 <tflink> anything else on this topic?
14:36:10 <garretraziel> yup
14:36:20 <garretraziel> task-dockerautotest successfully run
14:36:26 <jskladan> garretraziel: *yay*
14:36:29 <tflink> awesome
14:36:41 <tflink> I'd like to get that into production after beta freeze is over, then
14:37:07 <garretraziel> mkrizek said something about requiring to update libtaskotron in production or something
14:37:32 <tflink> yeah, that'll need to happen and there's a potential roadblock there
14:37:54 <tflink> but solving that was on the TODO list anyways :)
14:38:09 <tflink> specifically, infra wants to have everything packaged in fedora or at least built in koji
14:38:32 <tflink> at the moment, libtaskotron can not be built in koji due to missing deps
14:39:14 <tflink> so we'd need to at least package resultsdb_api in order to satisfy that requirement but I'd like to see libtaskotron in the fedora repos before we push dist-git style tasks to production anyways
14:39:38 <jskladan> tflink: what's missing apart of resultsdb_api?
14:39:48 <tflink> i think that's the only missing dep
14:40:10 * jskladan thought that it was up for review quite some time ago... Corrected I stand
14:40:24 <tflink> it might be reviewed already
14:40:32 <tflink> i was assuming that it wasn't
14:40:51 <tflink> but I know we need to make some changes to the libtaskotron specfile before it'll pass fedora review
14:42:09 <kparal> like those 777 dirs? can't be anything wrong with that :-)
14:42:19 <tflink> that's the issue I know of :-P
14:43:04 <tflink> testcloud got hung up on the same issue
14:43:09 <tflink> in review, I mean
14:44:00 <tflink> #action tflink to follow up on resultsdb_api packaging status and infra team to be sure of what all needs to be done before we can build libtaskotron in koji
14:44:05 <tflink> anything else on this?
14:44:33 * tflink takes that as a no, moves on
14:44:39 <tflink> #topic ABI Checking Task
14:45:12 <kparal> I'm very sorry, I still haven't followed up on that topic
14:45:29 <tflink> I've not caught up on this yet - is there anything else blocking this outside of the review for the task?
14:45:29 <tflink> and reconfiguring VMs to be bigger
14:45:49 <kparal> implementing the package whitelist or blacklist, I guess
14:46:35 <tflink> ok
14:47:18 * tflink would like to see that at least in dev before F24 final
14:47:44 <tflink> does anyone want the #action on coordinating that?
14:48:08 <mkrizek> I can do the deploying part
14:48:32 <kparal> I'd like to continue pushing that forward
14:48:56 <tflink> please do :)
14:49:13 <tflink> FWIW, I'd prefer to see it deployed sooner than worry about the white/black list
14:49:23 <kparal> ok
14:49:24 <tflink> for now, I'd be fine with a list of critpath packages in trigger
14:49:48 <mkrizek> which we can do "now", right?
14:49:56 <kparal> the definition changes, not sure how to do that well
14:50:19 <tflink> we might want to skip a few, I'd have to go back in my IRC logs to find the ones that won't work with our small clients
14:50:25 <tflink> or kparal can :)
14:50:38 <tflink> kparal: do you think you'll have the time for this this week?
14:51:07 <kparal> I have no idea, it's Beta release again :/ I'll try
14:51:22 * kparal found critpath at https://admin.fedoraproject.org/pkgdb/api/critpath
14:51:36 <kparal> so maybe we can download it regularly
14:51:44 <kparal> on the trigger machine
14:52:29 <tflink> for now, I'm fine with hard-coding it in config
14:53:17 <tflink> but that's not a long-term solution at all
14:53:28 <tflink> we're almost out of time - anything else on this?
14:53:49 <kparal> not here
14:53:54 <tflink> #action kparal to continue coordinating abi check work with the authors and mkrizek
14:54:04 <tflink> ok, moving on quickly to
14:54:10 <tflink> #topic Tasks
14:54:16 <tflink> is anyone in need of things to do?
14:54:27 <tflink> scratch that
14:54:36 <tflink> if you're in need of things to do, find me after the meeting
14:54:42 <tflink> #topic Open Floor
14:54:57 <tflink> Is there anything else that folks want to bring up?
14:55:29 <kparal> nothing here
14:56:34 * tflink lights the fuse, will close out shortly if nothing is brought up
14:57:59 <tflink> thanks for coming, everyone
14:58:04 * tflink will send out minutes shortly
14:58:07 <tflink> #endmeeting