14:03:50 <tflink> #startmeeting fedoraqa-devel
14:03:50 <tflink> #meetingname fedoraqa-devel
14:03:50 <tflink> #topic Roll Call
14:03:50 <zodbot> Meeting started Mon Aug 31 14:03:50 2015 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:50 <zodbot> The meeting name has been set to 'fedoraqa-devel'
14:04:01 * kparal is here as well
14:04:02 * roshi is here
14:04:05 <tflink> late, but wiki url: https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20150831-fedoraqadevel/
14:04:06 * jskladan here
14:04:08 * mkrizek is here
14:04:09 * garretraziel is here
14:04:20 * tflink was trying to figure out why nobody was in the meeting room until he realized that 2 != 1
14:04:22 * linux-modder here and  in -meeting for -docs
14:05:08 * tflink waits a few minutes for folks to add status bits to the wiki page
14:05:24 <tflink> lets get upcoming events out of the way while that happens
14:05:28 <tflink> #topic upcoming events
14:05:42 <tflink> #info 3 days of outages this week. cloud is today, buildsystem is Tuesday, most everything else is wednesday
14:05:55 <tflink> #info new version of testcloud has been released
14:06:05 <tflink> #info new version of testcloud has been released
14:06:10 <tflink> #undo
14:06:10 <zodbot> Removing item from minutes: INFO by tflink at 14:06:05 : new version of testcloud has been released
14:06:14 <kparal> tflink: does it include the logging fix?
14:06:19 <tflink> #info been upgrading phabricator regularly, will upgrade again before freeze
14:06:21 <tflink> kparal: i think so
14:06:25 * tflink checks
14:06:29 <kparal> and is it in our disposable-devel copr as well?
14:06:46 <tflink> looks like
14:06:55 <tflink> nope, i haven't built it since the release - roshi did it last night
14:07:03 * tflink will be doing so today
14:07:06 <kparal> thanks
14:07:46 <tflink> is anyone still adding bits to the status updates?
14:08:16 * tflink assumes not
14:08:22 <tflink> #topic status updates
14:08:38 <tflink> #info fixed inode runout on taskotron dev/stg - tflink
14:08:39 <tflink> #info looked into depcheck complaint, appears to be a missing feature (T482) - tflink
14:08:39 <tflink> #info got some bodhi comments turned back on - tflink, kparal
14:08:39 <tflink> #info still working to finish the f-e-k patch - tflink
14:08:39 <tflink> #info deprecated fake_fedorainfra - kparal
14:08:39 <tflink> #info lots of changes in the disposable-develop branch (ssh key discovery, input arguments escaping, testcloud messing with logging configuration) - kparal
14:08:41 <tflink> #info OpenQA: working on building 32bit images with virt-builder, lots of bugs, but newest version works - jsedlak
14:08:44 <tflink> #info OpenQA: created systemd services for periodic trigger running - jsedlak
14:08:46 <tflink> #info discussed the resultyaml format with kparal, and started implementing it - jskladan
14:09:04 <tflink> any comments, questions or things to add?
14:09:11 <roshi> I do
14:09:42 <kparal> garretraziel: it seems we will have no i686 install images for F24. at least that's what the internets say
14:09:43 <roshi> I've got the cloud-init stuff to work (mostly) with vmbuilder images - just some small stuff to iron out
14:09:50 <mkrizek> tflink: what's the f-e-k patch for? bodhi2?
14:10:01 <tflink> mkrizek: yep, updating the calls so they work with bodhi2
14:10:20 <kparal> roshi: great news
14:10:36 * tflink was hoping to finish it on friday, got distracted by the whole out-of-disk issue on dev/stg
14:10:53 <kparal> out of curiosity, has anyone tried fedora-gooey-karma?
14:10:56 <tflink> #info cloud-init stuff mostly working with taskotron-vmbuilder
14:11:11 <tflink> roshi: guesstimate on ETA?
14:11:17 <mkrizek> tflink: was artifacts eating up the space or something else too?
14:11:29 <tflink> mkrizek: it was out of inodes
14:11:34 <mkrizek> tflink: ah ok
14:11:58 * tflink wants to get apache configured to show gzipped text files so we can conserve more space as well
14:12:05 <roshi> the part of me that thinks things'll go well says today, but the part that knows better says later in the week
14:12:09 <roshi> so we'll go with later in the week
14:12:21 <tflink> :)
14:12:31 <tflink> have you been able to get the image size down?
14:12:37 * linux-modder hopes for  smooth  seas for  roshi
14:12:46 <roshi> tflink: me?
14:12:53 <roshi> thanks linux-modder :)
14:13:08 <tflink> roshi: or anyone
14:13:29 * tflink was surprised at how big the images coming out of taskotron-vmbuilder were when he's built images with it
14:13:31 * roshi hasn't been looking at making any images smaller
14:13:35 <linux-modder> can do some  testing for  cloud again later this week :)  had to  take a break for  ${dayjob / startup}
14:13:38 <tflink> it's less important than working :)
14:13:52 <linux-modder> ^^
14:13:53 <roshi> that's in the template though, you can resize those
14:13:56 <kparal> I'm not sure having a very small image size is actually helpful. because it means extremely spin up times (install times) for every test run, like with the base cloud image
14:14:04 <kparal> *long
14:14:08 <tflink> kparal: depends on why the image is big
14:14:47 <tflink> I'm not suggesting compression, I just don't understand why the minimal images were 2 or 3 times larger than the base cloud images
14:14:54 <kparal> if I installed just the core package set and shrank the disk size to minimum allowed by virt-builder (6GB), it was about 700MB I think
14:15:11 <tflink> hrm, maybe I'm mis-remembering
14:15:16 <kparal> I think the base cloud images are smaller than the core package set
14:15:18 * tflink will try again after the meeting
14:15:30 <tflink> yeah, the base cloud image isn't POSIX compliant
14:15:34 <kparal> they reduced it to the bone
14:15:43 <roshi> the base cloud image is ~220mb
14:15:45 <tflink> so they've removed somethings
14:15:46 <roshi> yeah, they did
14:16:15 <kparal> and also the base virt-builder images already contain some packages, they would have to be uninstalled if we want to conserve the size, I think
14:16:17 <tflink> either way, 700M doesn't worry me much - I recall seeing 1-2G/image but I'll retest to verify
14:16:34 <kparal> tflink: yes, 1-2G is the minimal package set
14:16:40 <kparal> core is about 700M I believe
14:17:18 <tflink> that's gonna add up pretty quick if we have multiple flavors/releases
14:17:48 <tflink> anyhow, we can discuss this in a ticket once there are more concrete numbers - I'm far more worried about making it work first :)
14:18:13 <tflink> any other comments/questions?
14:18:45 * roshi has none
14:18:52 <tflink> ok, moving on
14:18:56 <tflink> #topic tasking
14:19:03 <tflink> is anyone in need of tasks?
14:19:33 <kparal> if anybody is, I've reported many disposable-develop issues in the past few days :)
14:19:42 <kparal> and will probably continue to do so :/
14:20:17 <tflink> kparal: they need to be filed - there are certainly rough edges
14:21:02 <kparal> I filed them into Phab
14:21:16 * tflink wonders how lbrabec is doing with T575, will poke in ticket
14:21:43 <tflink> if anyone needs tasks, there are plenty of things which need to get done
14:22:18 * tflink is planning to get more ticket lists in place this week to write down which things are blockers, which are just NTH etc.
14:22:46 <linux-modder> I have some free time this week if  need be
14:22:55 <tflink> since we had a long meeting last week, we can end here but I'd like to touch on merging strategy/timing for disposable-develop if folks are willing
14:23:10 <roshi> sounds good go me
14:23:18 <kparal> sure, I wondered about the same
14:23:27 <tflink> linux-modder: feel free to ping me if you are looking for something
14:23:36 <tflink> #topic handling disposable-develop
14:23:41 <linux-modder> tflink,  after mtg  sure
14:24:03 <tflink> at some point, we're going to have to merge disposable-develop back into develop
14:24:17 <tflink> i suspect that merge is not going to be the prettiest thing ever
14:24:59 <kparal> I think we should start with making sure the switch will not break the existing process of running jobs on non-disposable clients
14:25:08 <tflink> I'd like to get that done sooner than later - most of the disposable stuff can be turned off
14:25:09 <kparal> so inspect the changes, maybe try to run it on dev
14:25:20 <tflink> agreed
14:25:54 <tflink> I'm even OK with the idea of multiple specfiles or odd conditionals for the testcloud and other unpackaged deps for now
14:26:08 <tflink> but that gets more into implementation
14:26:28 <tflink> can anyone think of a reason not to do it this week or next week at the latest?
14:27:00 <tflink> s/do it/ start hte process
14:27:06 <roshi> nope
14:28:04 <kparal> the question is whether we want to be strict during the merge review or accept it as it is and improve it gradually. because at least for me, I didn't have too many objections when pushing patches to disposable-develop, because I regarded it as temporary/in progress code
14:28:22 <kparal> but now that we want to pull it it, I'd probably want some changes improved, added unit tests, etc
14:28:25 <kparal> but that will take time
14:28:29 <tflink> my other question is about how to handle deps like testcloud - it's not needed on the leaf clients and takes a decent amount of time to download/install
14:28:40 <kparal> otoh, if we simply pull it in and "fix later", the later might never happen
14:29:05 <tflink> is there much in disposable-develop that's not up to snuff from a code quality perspective?
14:29:42 <kparal> I'd expect some of that, but I haven't reviewed it closely yet
14:30:07 <tflink> #info audit of disposable-develop differences needed before merging into develop
14:31:20 <kparal> with different deps for server/client (do we have some good names for them finally?), I don't see a better way than rpm subpackages
14:31:33 <tflink> if we want to keep the disposable-develop branch around to test more bleeding edge code, I'd like to at least get it to the point where develop is  ff-able to disposable-develop
14:32:06 <tflink> kparal: either that or look into modularizing more stuff
14:32:20 <kparal> what does the second involve?
14:32:40 <tflink> ie, see if we can treat the disposable client bits as an extension - similar to what I was talking about for the fedora-specific bits
14:33:22 <kparal> another solution is to rely on images with pre-built libtaskotron/testcloud, so that we don't need to download and install it
14:33:39 <tflink> we'd need to figure out what to do with the runner - checking for "if module_disposable installed, allow remote" and other stuff like that
14:34:03 <tflink> true
14:34:21 <kparal> even if we had it modular in python, we will still need rpm subpackages, I think
14:34:31 <tflink> agreed
14:35:03 <tflink> well, packages for submodules, subpackages ... either way
14:35:28 <kparal> ok
14:35:49 * tflink wonders if it would be worth trying for a quick PoC for the modular stuff before we merge disposable-develop into develop
14:36:09 <tflink> to see if it's even feasible in a reasonable amount of time
14:36:16 <kparal> this is something we can probably do easily after the merge
14:36:27 <kparal> not sure what we gain by delaying it
14:36:48 <tflink> not risking as much destabilization to develop
14:37:08 <tflink> but if we took the "make develop ff-able to disposable-develop" route, that could also work
14:37:31 <kparal> after the merge, what's the point of keeping disposable-develop around?
14:37:47 <tflink> if we wanted a place to land less-tested code
14:37:56 <kparal> feature branches, as usual?
14:38:02 <tflink> or did I misunderstand what you were talking about earlier
14:38:57 <kparal> you said you want to merge it soon. so I don't think modularization is so important to delay on it. so let's merge disposable-develop to develop and then play with modularization in feature/modularization
14:39:38 <tflink> makes sense to me - must have misunderstood what was said earlier
14:40:05 * tflink wants to start testing the disposable stuff
14:40:19 <tflink> I expect there will be problems and I'd like to start finding them
14:40:25 <kparal> we will need to deal with the huge dep chain one way or the other, but I don't think it blocks the disposable-develo merge
14:40:59 <tflink> it blocks (or is close to blocking) release but yeah, it doesn't have to block the merge
14:41:12 <tflink> the TAP replacement should help with the dep chain
14:41:55 <kparal> not too much, I think
14:42:14 <kparal> but we will get rid of some stuff unpackaged in Fedora, I guess
14:42:20 <tflink> #info will start looking into merging disposable-develop back into develop so testing can continue
14:43:06 <tflink> kparal: by 2 or so rpms, I think - could drop yamlish, bayeux. would end up replacing TAP13 with the new module
14:43:31 <tflink> any other comments/questions/thoughts on this?
14:43:44 <kparal> yeah, I meant download-size wise
14:44:00 <tflink> oh, yeah. those are pretty small deps
14:44:20 <tflink> if not, moving on to ...
14:44:27 <tflink> #topic open floor
14:44:40 <tflink> we're going to need a different chair next week if we have a qadevel meeting
14:44:49 <tflink> Monday is a US holiday and I won't be around
14:45:19 <tflink> any volunteers?
14:45:24 <tflink> or just cancel the meeting for next week?
14:45:25 <kparal> we can move it if you prefer
14:45:50 <kparal> otherwise, if no new new wants to participate, all the rest of us can just talk locally
14:46:00 <tflink> that works, too
14:46:01 <jskladan> kparal: ^^
14:46:20 <jskladan> I even volunteer to write down an email with "digest" of the said discussion
14:46:29 <tflink> jskladan: but you like meetings so much, I don't understand why you'd vote for that :)
14:46:31 * tflink ducks
14:46:34 <kparal> +1 for grumpy cat!
14:47:08 <kparal> so, it's agreed
14:47:17 <jskladan> tflink: http://www.quickmeme.com/img/3c/3c873fab525297372704eabec323c533ff4ffb829d81ac7a5385c63615544202.jpg
14:47:35 <tflink> #info qadevel meeting for 2015-09-05 is cancelled - will sync up via email, can reschedule if absolutely needed
14:47:57 <tflink> anything else?
14:48:06 <kparal> btw, I'm on PTO Wed-Fri
14:48:24 * tflink is gone Fri-Tue
14:49:01 * tflink lights fuse
14:49:06 <kparal> tflink: please put that into our team calendar if you can, thanks
14:49:06 * jskladan yay, anarchy!
14:49:17 <tflink> kparal: it's on my todo list for the day
14:49:42 <kparal> jskladan: I'll install a webcamera in the office to put you under supervision
14:50:02 <kparal> absolutely no chair races
14:50:13 <jskladan> http://cdn.meme.am/instances/45642987.jpg
14:50:33 <tflink> one advantage of a dynamic language - no "compiling" excuses :)
14:50:38 <kparal> but you're allowed to expand your cat image collection
14:50:56 <roshi> jskladan: do you just have a page open of cat memes for quick use at all times?
14:50:59 <jskladan> http://images1.content-wu.com/wu-cont/cms/whatuni/YayCat.jpg
14:51:12 <kparal> I believe he does
14:51:33 <kparal> it's in his contract
14:51:58 <jskladan> roshi: http://www.tikihumor.com/wp-content/uploads/sites/37/2012/02/the-internet-is-a-series-of-tubes-and-they-are-full-of-cats-500x373.jpg
14:52:25 <tflink> if there's nothing else, we're 10 minutes from the top of the hour
14:52:31 <tflink> Thanks for coming, everyone!
14:52:36 * tflink will send out minutes shortly
14:52:41 <tflink> #endmeeting