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