15:00:14 #startmeeting fedora-qadevel 15:00:15 Meeting started Mon Dec 7 15:00:14 2015 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:15 The meeting name has been set to 'fedora-qadevel' 15:00:15 #meetingname fedora-qadevel 15:00:15 #topic Roll Call 15:00:15 The meeting name has been set to 'fedora-qadevel' 15:00:21 how many folks do we have today? 15:00:24 * lbrabec is here 15:00:26 * mkrizek is here 15:00:27 * garretraziel is here 15:00:39 i assume kparal is not going to be present 15:00:42 kparal isn't coming today, he has some errands 15:00:46 * jskladan1 is here 15:00:48 mkrizek: I lied 15:01:00 well played :( 15:01:02 oh, the deception 15:01:19 kparal: http://i3.kym-cdn.com/entries/icons/facebook/000/010/390/pC8jf5t4eWCDKcMu.jpg 15:01:54 anyhow, let's get started 15:02:05 #topic Announcements and Information 15:02:14 #info fedmsgs enabled for taskotron production - tflink 15:02:14 #info disposable clients fixes - mkrizek 15:02:30 anything to add? 15:03:05 not from me 15:03:17 well 15:03:18 I don't think so - I played around with the imagefactory, but we can leave that to the other part of the meeting 15:03:26 for those of you who don't know, we have public openQA deployment - adamwill worked on it 15:03:32 we should have a really working bodhi retry code soon: https://github.com/fedora-infra/python-fedora/issues/144 15:04:29 #info public OpenQA deployment is live and working 15:04:48 and F21 got removed from yumrepoinfo, which caused an unexpected avalanche of error messages from our clients 15:05:00 yeah, still ongoing 15:05:08 i think there was an issue filed for that, no? 15:05:20 #link https://openqa.fedoraproject.org/ 15:05:23 mkrizek: you filed it against Bodhi, right? 15:05:42 kparal: it's fixed already, well the fix is commited 15:05:49 I suspect it's not deployed 15:05:54 * kparal nods 15:06:55 anything else? 15:07:10 not here 15:07:18 not here 15:07:28 K, moving on 15:07:35 #topic Tasking 15:07:55 Does anyone not have enough tasks to keep them busy? 15:08:04 I do 15:08:04 I'm good 15:08:19 er, misread 15:08:27 * mkrizek is good too 15:08:43 same here 15:08:51 I don't have enough days in the week, they are being taken from me :) 15:09:14 kparal: try going off of that vodka diet ;) 15:10:07 it's locked in my drawer, nobody knows 15:10:27 ok, let me know if you need tasks. I'm working to get the workboards in a better state so that the next tickets are more obvious 15:10:33 moving on 15:10:41 #topic Image Creation 15:11:03 This is one of the things which needs to happen before we can move disposable clients to production 15:11:49 the two tools that we've been looking at are taskotron-vmbuilder (virt-builder wrapper that kparal wrote) and imagefactory 15:12:08 jskladan1: you've been looking at this most recently, what thoughts do you have on the two tools 15:12:58 OK so I spent some "quality" time with Imagefactory the last week (and Tim has some experience too) - from my POW the tools are about the same for our needs, and there are only "minor" arguments to choose either IMO 15:13:42 the most important one being, whether we're able to get some logs out of the install process or not 15:14:09 both imagefactory and virt-builder (or more specifically oz-install and virt-install, in this case) 15:14:40 do you see that as a blocker, though? 15:14:41 do (AFAIK) the same thing - get a kernel, boot anaconda, and proceed installation driven by kickstart 15:15:00 so on a functional level, I don't really see that much of a difference 15:15:27 I figure that it would be very nice to have but if all else failed, we can triage by connecting to the VM during the build process to get logs 15:15:43 well - I kind of am in the camp of "good to know what went wrong", but I don't see it as a blocker - more of a nice to have 15:16:07 we haven't found something like --no-kill option for image builder, so you have very limited time to debug if something goes wrong 15:16:15 not sure about virt-install 15:16:23 and as you say - it can most probably be solved by tapping into the qemu serial console 15:16:29 s/imagebuilder/imagefactory 15:16:33 kparal: you can set a timeout in imagefactory 15:16:44 tflink: ok, that solves it 15:16:50 tflink: yeah, but that does not really solve the automated process of it 15:17:10 but as I said - I don't really treat is as a blocker, just a thing to think about 15:17:21 the only issues that won't catch are issues rebooting after initial install but that can be worked on by poking at the failed image 15:17:41 jskladan1: yeah, I was only talking about the ability to debug 15:18:05 * tflink agrees about logs, having to manually do a build and poke at it for debug is annoying, to say the least 15:18:41 so, that all said - I'd go with the imagefactory, personaly - because that's what releng uses 15:18:58 the fact that it's in python is nice, but after seeing the code, it does not really mean that much :D 15:19:39 yeah, it's a bit complex :) 15:19:48 any thoughts on the api in imagefactory? 15:20:12 tflink: API looks nice from the docs, I did not play around with it that much 15:20:26 especially since we'l be basically just creating a bunch of base images 15:20:31 one thought I had was to have imagefactory running on one system with the api active. client-hosts could query the api on a regular basis through cron and download new images when available 15:21:17 the api works for the most part, there is one blocker that I filed upstream https://github.com/redhat-imaging/imagefactory/issues/360 15:21:18 note for the others: imagefactory can also produce images ready for EC2, Docker, OpenStack and so on, based on the base-image (IIUIC) 15:21:59 should be a simple fix, was hoping for some input from upstream but was waiting to pester them until we had made more of a decision between virt-builder and imagefactory 15:22:18 other thoughts? 15:22:19 * kparal doesn't have any strong opinion 15:22:46 I suspect that the imagefactory API could also be used by openqa for at least some of its images 15:23:33 I have no idea how imagefactory works, but yeah, I suppose that we could also use it 15:23:58 tflink: kparal: before we make the final decision (I'm biased towards imgfac) - it might be usefull to "formalize" the use-case for taskotron 15:23:59 garretraziel: long story short, it makes qcow2 system images from kickstarts 15:24:44 just so we don't end up wanting some of the virt-builded functionality 15:24:54 yeah, but we mostly wants images without Fedora installed. is it possible to do this also? 15:25:31 specifically the ability to change the "base" images, and it's ability to serve those images to the devs/end users 15:25:34 not that I know of, it'd be mostly useful for the upgrade and reinstall cases 15:26:09 tflink, ok, we could use it for that 15:26:20 where I think you're using virt-builder ATM, no? 15:26:26 yes 15:26:49 if we just wan't to re-create images once a week, I don't think that running a full-blown install (instead of dnf update via virt-builder) is a problem. 15:27:15 even if it's once a day, I don't think it'd be a big problem 15:28:14 any other thoughts on this topic? 15:28:45 the difference is perhaps on users machines, where they could download 50MB of updates instead of 2GB of a new image. it depends what use case we want to optimize 15:28:48 it sounds like the consensus is something along the lines of "formalize the requirements to be sure but we're leaning towards imagefactory at the moment" 15:29:36 tflink: yup 15:29:53 * tflink wonders how many people will be running disposable clients with limited bandwidth 15:29:56 but virt-builder is anyway capable of optimizing just the base image, so you can't do it gradually every day, you always start from the same point. so once in a while, the user would still have to download a new base image 15:30:18 s/optimizing/adjusting 15:31:24 would "try running it in local mode" be an acceptable response? 15:32:16 I don't know how many people, but even some of us might grumble when they want to minimize startup time and need to download a few fresh images over their home connection 15:32:22 even if users did have the ability to update images instead of download new ones, they'd still have to download packages every time they ran a task - we don't have any caching 15:32:57 it depends on what task they run, they don't need to be developing depcheck 15:33:26 kparal: there are still the packages needed to run other tasks, even rpmlint downloads and installs one package 15:33:37 i take that back, rpmlint shoujld be in the image 15:34:19 I somehow assumed that we would be running "dnf update" on every start, and only now I realized I'm probably wrong 15:34:21 but even so, any of the tasks that won't work well with '--local' will likely need to download and/or install packages 15:34:44 is there a good reason to do that? 15:35:02 * tflink figured weekly updates would be enough 15:35:15 no, probably not, so my argument gets irrelevant 15:35:30 tflink: apart of getting the libtaskotron update ASAP, I can't think of any 15:35:39 but we can always trigger the image rebuild on new release 15:35:40 so... 15:35:51 we will probably be checking libtaskotron updates, I guess. but that's the whole system update 15:35:55 *that's not 15:36:36 so, no big deal, most probably 15:37:13 i think this still filters back to "more formal requirements, make sure we're not missing stuff" 15:37:25 jskladan1: are you up for taking that on? 15:37:25 ^^ 15:37:31 yup, noprob 15:37:54 #action jskladan to write up image building requirements to be more sure we're not missing anything before moving forward 15:38:03 anything else on image building? 15:38:08 nope 15:39:20 ok, moving on to the next topic 15:39:31 #topic Fedora Atomic Testing 15:39:44 that could have been phrased better 15:39:45 #undo 15:39:45 Removing item from minutes: 15:39:51 #topic Fedora Cloud/Atomic Testing 15:40:25 Long story short, there are currently two systems running automated tests in infra - taskotron and autocloud 15:40:46 autocloud was created to address automated testing needs for the Two Week Atomic initiative 15:41:08 but the longer term plan is to get that integrated into taskotron before too much longer 15:42:08 I have some really hacky ideas that could make that happen sooner than later but there's still the upstream atomic suite that'd be nice to run 15:42:57 unfortunately, it's not 100% compatible with how taskotron works ATM 15:43:44 I don't think there's much else to say about this topic, though 15:43:45 tflink: what are the incompatibilities (in short)? 15:43:57 jskladan1: they depend on jenkins-job-builder 15:44:04 which needs jenkins and openstack 15:44:40 I'm hoping that it wouldn't be too bad to write an interface for jjb such that it could work with taskotron 15:45:14 they also do a bunch of stuff with ansible, which I'd like to have in taskotron before too long but might take a bit to get implemented 15:46:46 any other thoughts/questions? 15:47:42 none here. I still need to look at those atomic tests you sent me some time ago (if it's still relevant) 15:47:53 yeah, that's the suite I'm talking about 15:48:53 as a reference, I think the suite is still behind the RH firewall but upstream wants it run on fedora so it'll probably be released at some point 15:49:46 ok, good to know 15:49:57 i suspect this will come up again, mostly wanted to give an update and see if there were questions 15:50:05 That's all I had for today 15:50:08 which moves us on to 15:50:11 #topic Open Floor 15:50:17 Any other items to bring up? 15:50:46 http://www.quickmeme.com/img/71/717e379ed775babf15aacf32e055b8627a456efaab5e2da975c1002cac25065c.jpg 15:51:00 (yeah, I have nothing...) 15:51:56 the deafening silence makes me think "no" :) 15:52:02 thanks for coming everyone 15:52:07 * tflink will send out minutes shortly 15:52:12 #endmeeting