14:03:50 #startmeeting fedoraqa-devel 14:03:50 #meetingname fedoraqa-devel 14:03:50 #topic Roll Call 14:03:50 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:50 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 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 lets get upcoming events out of the way while that happens 14:05:28 #topic upcoming events 14:05:42 #info 3 days of outages this week. cloud is today, buildsystem is Tuesday, most everything else is wednesday 14:05:55 #info new version of testcloud has been released 14:06:05 #info new version of testcloud has been released 14:06:10 #undo 14:06:10 Removing item from minutes: INFO by tflink at 14:06:05 : new version of testcloud has been released 14:06:14 tflink: does it include the logging fix? 14:06:19 #info been upgrading phabricator regularly, will upgrade again before freeze 14:06:21 kparal: i think so 14:06:25 * tflink checks 14:06:29 and is it in our disposable-devel copr as well? 14:06:46 looks like 14:06:55 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 thanks 14:07:46 is anyone still adding bits to the status updates? 14:08:16 * tflink assumes not 14:08:22 #topic status updates 14:08:38 #info fixed inode runout on taskotron dev/stg - tflink 14:08:39 #info looked into depcheck complaint, appears to be a missing feature (T482) - tflink 14:08:39 #info got some bodhi comments turned back on - tflink, kparal 14:08:39 #info still working to finish the f-e-k patch - tflink 14:08:39 #info deprecated fake_fedorainfra - kparal 14:08:39 #info lots of changes in the disposable-develop branch (ssh key discovery, input arguments escaping, testcloud messing with logging configuration) - kparal 14:08:41 #info OpenQA: working on building 32bit images with virt-builder, lots of bugs, but newest version works - jsedlak 14:08:44 #info OpenQA: created systemd services for periodic trigger running - jsedlak 14:08:46 #info discussed the resultyaml format with kparal, and started implementing it - jskladan 14:09:04 any comments, questions or things to add? 14:09:11 I do 14:09:42 garretraziel: it seems we will have no i686 install images for F24. at least that's what the internets say 14:09:43 I've got the cloud-init stuff to work (mostly) with vmbuilder images - just some small stuff to iron out 14:09:50 tflink: what's the f-e-k patch for? bodhi2? 14:10:01 mkrizek: yep, updating the calls so they work with bodhi2 14:10:20 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 out of curiosity, has anyone tried fedora-gooey-karma? 14:10:56 #info cloud-init stuff mostly working with taskotron-vmbuilder 14:11:11 roshi: guesstimate on ETA? 14:11:17 tflink: was artifacts eating up the space or something else too? 14:11:29 mkrizek: it was out of inodes 14:11:34 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 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 so we'll go with later in the week 14:12:21 :) 14:12:31 have you been able to get the image size down? 14:12:37 * linux-modder hopes for smooth seas for roshi 14:12:46 tflink: me? 14:12:53 thanks linux-modder :) 14:13:08 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 can do some testing for cloud again later this week :) had to take a break for ${dayjob / startup} 14:13:38 it's less important than working :) 14:13:52 ^^ 14:13:53 that's in the template though, you can resize those 14:13:56 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 *long 14:14:08 kparal: depends on why the image is big 14:14:47 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 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 hrm, maybe I'm mis-remembering 14:15:16 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 yeah, the base cloud image isn't POSIX compliant 14:15:34 they reduced it to the bone 14:15:43 the base cloud image is ~220mb 14:15:45 so they've removed somethings 14:15:46 yeah, they did 14:16:15 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 either way, 700M doesn't worry me much - I recall seeing 1-2G/image but I'll retest to verify 14:16:34 tflink: yes, 1-2G is the minimal package set 14:16:40 core is about 700M I believe 14:17:18 that's gonna add up pretty quick if we have multiple flavors/releases 14:17:48 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 any other comments/questions? 14:18:45 * roshi has none 14:18:52 ok, moving on 14:18:56 #topic tasking 14:19:03 is anyone in need of tasks? 14:19:33 if anybody is, I've reported many disposable-develop issues in the past few days :) 14:19:42 and will probably continue to do so :/ 14:20:17 kparal: they need to be filed - there are certainly rough edges 14:21:02 I filed them into Phab 14:21:16 * tflink wonders how lbrabec is doing with T575, will poke in ticket 14:21:43 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 I have some free time this week if need be 14:22:55 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 sounds good go me 14:23:18 sure, I wondered about the same 14:23:27 linux-modder: feel free to ping me if you are looking for something 14:23:36 #topic handling disposable-develop 14:23:41 tflink, after mtg sure 14:24:03 at some point, we're going to have to merge disposable-develop back into develop 14:24:17 i suspect that merge is not going to be the prettiest thing ever 14:24:59 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 I'd like to get that done sooner than later - most of the disposable stuff can be turned off 14:25:09 so inspect the changes, maybe try to run it on dev 14:25:20 agreed 14:25:54 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 but that gets more into implementation 14:26:28 can anyone think of a reason not to do it this week or next week at the latest? 14:27:00 s/do it/ start hte process 14:27:06 nope 14:28:04 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 but now that we want to pull it it, I'd probably want some changes improved, added unit tests, etc 14:28:25 but that will take time 14:28:29 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 otoh, if we simply pull it in and "fix later", the later might never happen 14:29:05 is there much in disposable-develop that's not up to snuff from a code quality perspective? 14:29:42 I'd expect some of that, but I haven't reviewed it closely yet 14:30:07 #info audit of disposable-develop differences needed before merging into develop 14:31:20 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 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 kparal: either that or look into modularizing more stuff 14:32:20 what does the second involve? 14:32:40 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 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 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 true 14:34:21 even if we had it modular in python, we will still need rpm subpackages, I think 14:34:31 agreed 14:35:03 well, packages for submodules, subpackages ... either way 14:35:28 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 to see if it's even feasible in a reasonable amount of time 14:36:16 this is something we can probably do easily after the merge 14:36:27 not sure what we gain by delaying it 14:36:48 not risking as much destabilization to develop 14:37:08 but if we took the "make develop ff-able to disposable-develop" route, that could also work 14:37:31 after the merge, what's the point of keeping disposable-develop around? 14:37:47 if we wanted a place to land less-tested code 14:37:56 feature branches, as usual? 14:38:02 or did I misunderstand what you were talking about earlier 14:38:57 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 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 I expect there will be problems and I'd like to start finding them 14:40:25 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 it blocks (or is close to blocking) release but yeah, it doesn't have to block the merge 14:41:12 the TAP replacement should help with the dep chain 14:41:55 not too much, I think 14:42:14 but we will get rid of some stuff unpackaged in Fedora, I guess 14:42:20 #info will start looking into merging disposable-develop back into develop so testing can continue 14:43:06 kparal: by 2 or so rpms, I think - could drop yamlish, bayeux. would end up replacing TAP13 with the new module 14:43:31 any other comments/questions/thoughts on this? 14:43:44 yeah, I meant download-size wise 14:44:00 oh, yeah. those are pretty small deps 14:44:20 if not, moving on to ... 14:44:27 #topic open floor 14:44:40 we're going to need a different chair next week if we have a qadevel meeting 14:44:49 Monday is a US holiday and I won't be around 14:45:19 any volunteers? 14:45:24 or just cancel the meeting for next week? 14:45:25 we can move it if you prefer 14:45:50 otherwise, if no new new wants to participate, all the rest of us can just talk locally 14:46:00 that works, too 14:46:01 kparal: ^^ 14:46:20 I even volunteer to write down an email with "digest" of the said discussion 14:46:29 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 +1 for grumpy cat! 14:47:08 so, it's agreed 14:47:17 tflink: http://www.quickmeme.com/img/3c/3c873fab525297372704eabec323c533ff4ffb829d81ac7a5385c63615544202.jpg 14:47:35 #info qadevel meeting for 2015-09-05 is cancelled - will sync up via email, can reschedule if absolutely needed 14:47:57 anything else? 14:48:06 btw, I'm on PTO Wed-Fri 14:48:24 * tflink is gone Fri-Tue 14:49:01 * tflink lights fuse 14:49:06 tflink: please put that into our team calendar if you can, thanks 14:49:06 * jskladan yay, anarchy! 14:49:17 kparal: it's on my todo list for the day 14:49:42 jskladan: I'll install a webcamera in the office to put you under supervision 14:50:02 absolutely no chair races 14:50:13 http://cdn.meme.am/instances/45642987.jpg 14:50:33 one advantage of a dynamic language - no "compiling" excuses :) 14:50:38 but you're allowed to expand your cat image collection 14:50:56 jskladan: do you just have a page open of cat memes for quick use at all times? 14:50:59 http://images1.content-wu.com/wu-cont/cms/whatuni/YayCat.jpg 14:51:12 I believe he does 14:51:33 it's in his contract 14:51:58 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 if there's nothing else, we're 10 minutes from the top of the hour 14:52:31 Thanks for coming, everyone! 14:52:36 * tflink will send out minutes shortly 14:52:41 #endmeeting