fedora-qadevel
LOGS
15:00:42 <tflink> #startmeeting fedora-qadevel
15:00:42 <zodbot> Meeting started Mon Feb 27 15:00:42 2017 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:42 <zodbot> The meeting name has been set to 'fedora-qadevel'
15:00:42 <tflink> #meetingname fedora-qadevel
15:00:42 <zodbot> The meeting name has been set to 'fedora-qadevel'
15:00:42 <tflink> #topic Roll Call
15:01:06 * mkrizek 
15:01:28 * kparal is here
15:01:28 * garretraziel is here
15:02:43 <tflink> #chair mkrizek kparal garretraziel
15:02:43 <zodbot> Current chairs: garretraziel kparal mkrizek tflink
15:03:40 <tflink> hrm, no josef and no lukas, I assume?
15:03:44 * roshi is here
15:04:21 <tflink> #chair roshi
15:04:21 <zodbot> Current chairs: garretraziel kparal mkrizek roshi tflink
15:04:50 * kparal shrugs
15:05:03 * tflink wonders what would happen if he unchaired himself as meeting owner - not sure if zodbot would care
15:05:33 <tflink> which means that it's time to get started before we try to break zodbot
15:05:43 <tflink> #topic Announcements and Information
15:05:52 <tflink> #info new resultsdb* pushed to production (frontend search fixed) -- kparal and mkrizek
15:05:52 <tflink> #info deployed more fixes to get rid of zombie VMs (new buildbot step to make sure VM is killed, more blacklisted packages for task-abicheck) -- kparal and mkrizek
15:05:52 <tflink> #link https://phab.qa.fedoraproject.org/T905
15:05:52 <tflink> #info fedora-gooey-karma is now under our ownership and maintenance, coremodule will try to port it to Bodhi 2.0 API -- kparal
15:05:53 <tflink> #link https://pagure.io/fedora-qa/fedora-gooey-karma
15:05:55 <tflink> #info all our taskotron servers have now fake F26 image to avoid constant crashes (due to F26 image being totally broken), use F25 one instead. The image is deployed with a 2-week future date. I'll continue doing so until F26 image is fixed or we get a release-specific task. -- kparal
15:05:59 <tflink> #info taskotron-stg fixed to schedule koji_build tasks -- mkrizek
15:06:01 <tflink> #link https://phab.qa.fedoraproject.org/T917
15:06:43 <tflink> any questions or comments?
15:06:58 <garretraziel> none here
15:07:02 <tflink> if the f26 tasks aren't just crashing, that'd be awesome
15:07:21 <kparal> clearly we need to re-evaluate our approach to rawhide testing :/
15:07:28 <roshi> f-e-k I think has some of the same issues
15:07:41 <roshi> danofsatx mentioned errors he was getting over the weekend
15:07:48 * roshi isn't sure if they're related
15:08:05 <kparal> I'm not aware of f-e-k issues
15:08:07 <tflink> kparal: yeah, something needs to change
15:08:41 <kparal> either we need to start gating rawhide composes soon, or use a different approach until that happens :)
15:08:57 <tflink> isn't the current issue cloud-init?
15:09:19 * tflink remembers seeing someone with a scratch build a few weeks ago but isn't sure what happened with that
15:09:22 <kparal> not sure, but f26 composes had many issues over the last months
15:09:26 <kparal> many of them not related to could-init
15:09:34 <kparal> even systemd was completely broken
15:09:51 <tflink> i mean that the ones that actually composed would fail to allow login due to a cloud-init issue
15:10:08 <kparal> it's possible
15:10:12 <kparal> don't know
15:10:47 * tflink would like to look into moving over to openstack's diskimagebuilder instead of using imagefactory
15:11:07 <tflink> but that is a topic for another day
15:11:15 <tflink> any other questions or comments?
15:11:32 <kparal> nope
15:11:36 <garretraziel> tflink: jskladan tried to solve that
15:11:55 <garretraziel> we had proof of concept of building images using openQA
15:12:07 <tflink> oh yeah, I forgot about that.
15:12:21 * tflink must need more coffee
15:13:03 * tflink assumes that is all for this topic and moves on
15:13:22 <tflink> #topic Documentation
15:13:42 <tflink> I keep putting this as an agenda item and then neglect to follow up on it :-/
15:14:28 <tflink> the order is a bit off here but I'd like to turn on dist-git tasks in at least dev this week and it would be nice to have up-to-date docs
15:14:47 <tflink> if folks have the cycles, please look through the current docs and make changes to what may be out of date now
15:15:06 <tflink> https://qa.fedoraproject.org/docs/libtaskotron/latest/
15:16:08 <tflink> that's about all I had on this. nice and quick :)
15:16:09 <kparal> is dist-git namespace ready and do we have some guinea pig tasks?
15:16:42 <tflink> mostly, yes. the conclusion seems to be just do something and if it needs to change, it can change
15:16:43 <kparal> except for dockerautotest, that's one I know about
15:17:04 <tflink> pingou has volunteered to be a guinea pig with the pagure package
15:17:11 <kparal> great
15:17:21 <tflink> I think that the modularity folks have some tests for sed
15:17:37 <kparal> well I wrote a "test suite" for gzip for last flock :)
15:17:41 <kparal> I can put it in :)
15:17:44 <tflink> sounds good
15:18:07 <tflink> huh, i forgot to put the new topic in
15:18:12 <tflink> #topic Making taskotron images public
15:18:15 <tflink> whoops
15:18:34 <kparal> that's fine, that's all I wanted to ask wrt documentation
15:18:46 <tflink> so, I tried doing this last week and managed to kill qa.fp.o in the process
15:19:16 * tflink didn't realize that the imagefactory client scripts downloaded an uncompressed image before compressing it
15:19:40 <tflink> and as I type this, I remember why that wouldn't have worked anyways
15:19:58 <kparal> we modify it before compressing, iirc
15:20:04 <tflink> what an auspicious start to the week
15:20:04 <kparal> yum repos
15:20:30 <tflink> the production images have hardcoded values for hosts, I think
15:20:34 <tflink> or did we get rid of that?
15:21:31 <kparal> I don't know, but the public ones need to have the standard yum repos files
15:21:41 <kparal> so either we modify the internal ones or the public ones
15:22:29 <kparal> (or standard hosts files, whatever)
15:22:32 * tflink needs to do some more homework on the details here
15:22:54 <kparal> jskladan should be able to help, once he's around
15:23:09 <tflink> I was wondering if anyone had other suggestions on where to host the images
15:23:22 <tflink> since the disk on qa-prod01 is not enough to process images
15:23:57 <mkrizek> client-hosts have lots of space
15:24:54 <tflink> but they're not public
15:25:38 * tflink will probably end up bumping the disk on qa-prod01 at the next update/reboot outage
15:27:15 <tflink> anyone? bueller?
15:27:35 * tflink takes that as a no, moves on
15:27:45 <tflink> #topic Dist-Git Task Storage
15:28:39 <tflink> so, this one has been kicking around for way too long
15:29:19 <tflink> long story short, I'd like to get this enabled in at least dev this week
15:29:39 <tflink> and potentially listening to koji.stg
15:30:10 <kparal> so, what exactly is this?
15:30:19 <tflink> what exactly is what?
15:30:25 <tflink> what would be enabled?
15:30:53 <tflink> the idea is to have either a test_build/ directory or a test/ directory in the repo to start with
15:31:27 * tflink wants to poke at the dist-git seed to see if there are packages already using test/ and if so, how many
15:31:43 <kparal> ok
15:33:14 <tflink> any huge objections?
15:33:52 <mkrizek> no objections here
15:34:28 <kparal> nope
15:34:58 <tflink> cool, I'll send out emails once this is enabled in dev
15:35:09 <tflink> which reminds me of one last (hopefully quick) topic
15:35:16 <tflink> #topic usage of taskotron-dev
15:36:04 <tflink> I think that I mentioned this in #fedora-qa last week but I'd like to start using taskotron-dev for the dist-git storage testing and more of a "place to test early things" rather than mostly a replication of stg
15:36:50 <tflink> I just wanted to mention it again and see if there were any objections
15:37:10 <mkrizek> sounds good to me
15:37:12 <kparal> does it mean it will deviate from develop head, or be closer to it?
15:37:13 <roshi> what kinds of things currently go into -dev?
15:37:40 <roshi> dev branch of taskotron? or dev branch of any additions?
15:37:52 <tflink> kparal: for the moment, it would probably deviate until all the changes made it back into develop
15:37:52 <roshi> so when I finish this trigger, it'll go to dev first?
15:38:02 <tflink> roshi: the taskotron-dev deployment
15:38:12 <tflink> roshi: yep
15:38:38 <roshi> I wasn't sure what all comprised a "deployment"
15:39:04 <tflink> an entire setup of trigger, master, client-host, resultsdb, resultsdb_frontend and execdb
15:39:23 <kparal> I'm basically in favor, just it would be good for all of us to be aware what's currently deployed, so that we don't overwrite it next time we decide to create a new release
15:39:57 <kparal> or test a new patch or whatever
15:40:10 <kparal> i.e. new testcloud last week
15:40:18 <kparal> s/i.e./e.g.
15:40:19 <roshi> gotcha
15:40:34 * roshi always gets those two confused (i.e.,e.g.)
15:40:42 <kparal> so atm I'm going to consult tflink every time until cancelled :)
15:41:47 <tflink> any thoughts on how to keep in sync on this?
15:42:22 <tflink> other thoughts, rather
15:42:43 * roshi has none
15:43:36 <tflink> for the short term, this'll work but at some point, I think we'll want to find something different
15:43:45 <kparal> not really. if this is a long-term plan, maybe we can deploy it elsewhere and re-use the buildbot workers?
15:44:12 <kparal> or, you know, containers. containers everything! :)
15:44:15 * tflink talked with puiterwijk and AFAIK, the restrictions of having released koji builds are less strict for dev since it isn't a production service
15:44:31 <tflink> I'm hoping it isn't a long term plan
15:44:41 <puiterwijk> Correct. On dev you can do basically what you want, as long as you don't go attack the rest of the infra
15:44:52 <tflink> having a bus number of 1 is never a good idea
15:44:53 <puiterwijk> (and don't add it to nagios. Then I might come and chase you down)
15:45:07 <tflink> i don't think that dev is in nagios
15:45:13 <tflink> qa11 is, though
15:46:23 <tflink> anyhow, I wanted to check with folks to see if there were objections and it sounds like there aren't any at the moment
15:46:33 <tflink> let me know objections come up, though
15:46:50 <tflink> we will need to figure out a better solution if this carries on
15:46:56 <tflink> but that brings us to
15:46:59 <tflink> #topic Open Floor
15:47:10 <tflink> any other topics to cover that didn't get mentioned above?
15:47:21 <kparal> nothing from me
15:47:26 <mkrizek> none here
15:48:04 <garretraziel> nope
15:48:10 <tflink> ok, sounds like we can end with 12 minutes to spare
15:48:15 <tflink> thanks for coming, everyone
15:48:19 * tflink will send out minutes shortly
15:48:22 <tflink> #endmeeting