15:00:14 <tflink> #startmeeting fedora-qadevel 15:00:15 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:15 <zodbot> The meeting name has been set to 'fedora-qadevel' 15:00:15 <tflink> #meetingname fedora-qadevel 15:00:15 <tflink> #topic Roll Call 15:00:15 <zodbot> The meeting name has been set to 'fedora-qadevel' 15:00:21 <tflink> 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 <tflink> i assume kparal is not going to be present 15:00:42 <mkrizek> kparal isn't coming today, he has some errands 15:00:46 * jskladan1 is here 15:00:48 <kparal> mkrizek: I lied 15:01:00 <mkrizek> well played :( 15:01:02 <tflink> oh, the deception 15:01:19 <jskladan1> kparal: http://i3.kym-cdn.com/entries/icons/facebook/000/010/390/pC8jf5t4eWCDKcMu.jpg 15:01:54 <tflink> anyhow, let's get started 15:02:05 <tflink> #topic Announcements and Information 15:02:14 <tflink> #info fedmsgs enabled for taskotron production - tflink 15:02:14 <tflink> #info disposable clients fixes - mkrizek 15:02:30 <tflink> anything to add? 15:03:05 <kparal> not from me 15:03:17 <kparal> well 15:03:18 <jskladan1> 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 <garretraziel> for those of you who don't know, we have public openQA deployment - adamwill worked on it 15:03:32 <kparal> we should have a really working bodhi retry code soon: https://github.com/fedora-infra/python-fedora/issues/144 15:04:29 <tflink> #info public OpenQA deployment is live and working 15:04:48 <kparal> and F21 got removed from yumrepoinfo, which caused an unexpected avalanche of error messages from our clients 15:05:00 <tflink> yeah, still ongoing 15:05:08 <tflink> i think there was an issue filed for that, no? 15:05:20 <garretraziel> #link https://openqa.fedoraproject.org/ 15:05:23 <kparal> mkrizek: you filed it against Bodhi, right? 15:05:42 <mkrizek> kparal: it's fixed already, well the fix is commited 15:05:49 <mkrizek> I suspect it's not deployed 15:05:54 * kparal nods 15:06:55 <tflink> anything else? 15:07:10 <kparal> not here 15:07:18 <mkrizek> not here 15:07:28 <tflink> K, moving on 15:07:35 <tflink> #topic Tasking 15:07:55 <tflink> Does anyone not have enough tasks to keep them busy? 15:08:04 <mkrizek> I do 15:08:04 <jskladan1> I'm good 15:08:19 <mkrizek> er, misread 15:08:27 * mkrizek is good too 15:08:43 <lbrabec> same here 15:08:51 <kparal> I don't have enough days in the week, they are being taken from me :) 15:09:14 <jskladan1> kparal: try going off of that vodka diet ;) 15:10:07 <kparal> it's locked in my drawer, nobody knows 15:10:27 <tflink> 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 <tflink> moving on 15:10:41 <tflink> #topic Image Creation 15:11:03 <tflink> This is one of the things which needs to happen before we can move disposable clients to production 15:11:49 <tflink> the two tools that we've been looking at are taskotron-vmbuilder (virt-builder wrapper that kparal wrote) and imagefactory 15:12:08 <tflink> jskladan1: you've been looking at this most recently, what thoughts do you have on the two tools 15:12:58 <jskladan1> 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 <jskladan1> the most important one being, whether we're able to get some logs out of the install process or not 15:14:09 <jskladan1> both imagefactory and virt-builder (or more specifically oz-install and virt-install, in this case) 15:14:40 <tflink> do you see that as a blocker, though? 15:14:41 <jskladan1> do (AFAIK) the same thing - get a kernel, boot anaconda, and proceed installation driven by kickstart 15:15:00 <jskladan1> so on a functional level, I don't really see that much of a difference 15:15:27 <tflink> 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 <jskladan1> 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 <kparal> 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 <kparal> not sure about virt-install 15:16:23 <jskladan1> and as you say - it can most probably be solved by tapping into the qemu serial console 15:16:29 <kparal> s/imagebuilder/imagefactory 15:16:33 <tflink> kparal: you can set a timeout in imagefactory 15:16:44 <kparal> tflink: ok, that solves it 15:16:50 <jskladan1> tflink: yeah, but that does not really solve the automated process of it 15:17:10 <jskladan1> but as I said - I don't really treat is as a blocker, just a thing to think about 15:17:21 <tflink> 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 <tflink> 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 <jskladan1> so, that all said - I'd go with the imagefactory, personaly - because that's what releng uses 15:18:58 <jskladan1> 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 <tflink> yeah, it's a bit complex :) 15:19:48 <tflink> any thoughts on the api in imagefactory? 15:20:12 <jskladan1> tflink: API looks nice from the docs, I did not play around with it that much 15:20:26 <jskladan1> especially since we'l be basically just creating a bunch of base images 15:20:31 <tflink> 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 <tflink> 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 <jskladan1> 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 <tflink> 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 <tflink> other thoughts? 15:22:19 * kparal doesn't have any strong opinion 15:22:46 <tflink> I suspect that the imagefactory API could also be used by openqa for at least some of its images 15:23:33 <garretraziel> I have no idea how imagefactory works, but yeah, I suppose that we could also use it 15:23:58 <jskladan1> 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 <tflink> garretraziel: long story short, it makes qcow2 system images from kickstarts 15:24:44 <jskladan1> just so we don't end up wanting some of the virt-builded functionality 15:24:54 <garretraziel> yeah, but we mostly wants images without Fedora installed. is it possible to do this also? 15:25:31 <jskladan1> specifically the ability to change the "base" images, and it's ability to serve those images to the devs/end users 15:25:34 <tflink> not that I know of, it'd be mostly useful for the upgrade and reinstall cases 15:26:09 <garretraziel> tflink, ok, we could use it for that 15:26:20 <tflink> where I think you're using virt-builder ATM, no? 15:26:26 <garretraziel> yes 15:26:49 <jskladan1> 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 <tflink> even if it's once a day, I don't think it'd be a big problem 15:28:14 <tflink> any other thoughts on this topic? 15:28:45 <kparal> 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 <tflink> 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 <jskladan1> tflink: yup 15:29:53 * tflink wonders how many people will be running disposable clients with limited bandwidth 15:29:56 <kparal> 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 <kparal> s/optimizing/adjusting 15:31:24 <tflink> would "try running it in local mode" be an acceptable response? 15:32:16 <kparal> 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 <tflink> 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 <kparal> it depends on what task they run, they don't need to be developing depcheck 15:33:26 <tflink> kparal: there are still the packages needed to run other tasks, even rpmlint downloads and installs one package 15:33:37 <tflink> i take that back, rpmlint shoujld be in the image 15:34:19 <kparal> 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 <tflink> 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 <tflink> is there a good reason to do that? 15:35:02 * tflink figured weekly updates would be enough 15:35:15 <kparal> no, probably not, so my argument gets irrelevant 15:35:30 <jskladan1> tflink: apart of getting the libtaskotron update ASAP, I can't think of any 15:35:39 <jskladan1> but we can always trigger the image rebuild on new release 15:35:40 <jskladan1> so... 15:35:51 <kparal> we will probably be checking libtaskotron updates, I guess. but that's the whole system update 15:35:55 <kparal> *that's not 15:36:36 <kparal> so, no big deal, most probably 15:37:13 <tflink> i think this still filters back to "more formal requirements, make sure we're not missing stuff" 15:37:25 <tflink> jskladan1: are you up for taking that on? 15:37:25 <jskladan1> ^^ 15:37:31 <jskladan1> yup, noprob 15:37:54 <tflink> #action jskladan to write up image building requirements to be more sure we're not missing anything before moving forward 15:38:03 <tflink> anything else on image building? 15:38:08 <jskladan1> nope 15:39:20 <tflink> ok, moving on to the next topic 15:39:31 <tflink> #topic Fedora Atomic Testing 15:39:44 <tflink> that could have been phrased better 15:39:45 <tflink> #undo 15:39:45 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x32b8e590> 15:39:51 <tflink> #topic Fedora Cloud/Atomic Testing 15:40:25 <tflink> Long story short, there are currently two systems running automated tests in infra - taskotron and autocloud 15:40:46 <tflink> autocloud was created to address automated testing needs for the Two Week Atomic initiative 15:41:08 <tflink> but the longer term plan is to get that integrated into taskotron before too much longer 15:42:08 <tflink> 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 <tflink> unfortunately, it's not 100% compatible with how taskotron works ATM 15:43:44 <tflink> I don't think there's much else to say about this topic, though 15:43:45 <jskladan1> tflink: what are the incompatibilities (in short)? 15:43:57 <tflink> jskladan1: they depend on jenkins-job-builder 15:44:04 <tflink> which needs jenkins and openstack 15:44:40 <tflink> 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 <tflink> 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 <tflink> any other thoughts/questions? 15:47:42 <jskladan1> 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 <tflink> yeah, that's the suite I'm talking about 15:48:53 <tflink> 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 <jskladan1> ok, good to know 15:49:57 <tflink> i suspect this will come up again, mostly wanted to give an update and see if there were questions 15:50:05 <tflink> That's all I had for today 15:50:08 <tflink> which moves us on to 15:50:11 <tflink> #topic Open Floor 15:50:17 <tflink> Any other items to bring up? 15:50:46 <jskladan1> http://www.quickmeme.com/img/71/717e379ed775babf15aacf32e055b8627a456efaab5e2da975c1002cac25065c.jpg 15:51:00 <jskladan1> (yeah, I have nothing...) 15:51:56 <tflink> the deafening silence makes me think "no" :) 15:52:02 <tflink> thanks for coming everyone 15:52:07 * tflink will send out minutes shortly 15:52:12 <tflink> #endmeeting