15:00:42 #startmeeting fedora-qadevel 15:00:42 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:42 The meeting name has been set to 'fedora-qadevel' 15:00:42 #meetingname fedora-qadevel 15:00:42 The meeting name has been set to 'fedora-qadevel' 15:00:42 #topic Roll Call 15:01:06 * mkrizek 15:01:28 * kparal is here 15:01:28 * garretraziel is here 15:02:43 #chair mkrizek kparal garretraziel 15:02:43 Current chairs: garretraziel kparal mkrizek tflink 15:03:40 hrm, no josef and no lukas, I assume? 15:03:44 * roshi is here 15:04:21 #chair roshi 15:04:21 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 which means that it's time to get started before we try to break zodbot 15:05:43 #topic Announcements and Information 15:05:52 #info new resultsdb* pushed to production (frontend search fixed) -- kparal and mkrizek 15:05:52 #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 #link https://phab.qa.fedoraproject.org/T905 15:05:52 #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 #link https://pagure.io/fedora-qa/fedora-gooey-karma 15:05:55 #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 #info taskotron-stg fixed to schedule koji_build tasks -- mkrizek 15:06:01 #link https://phab.qa.fedoraproject.org/T917 15:06:43 any questions or comments? 15:06:58 none here 15:07:02 if the f26 tasks aren't just crashing, that'd be awesome 15:07:21 clearly we need to re-evaluate our approach to rawhide testing :/ 15:07:28 f-e-k I think has some of the same issues 15:07:41 danofsatx mentioned errors he was getting over the weekend 15:07:48 * roshi isn't sure if they're related 15:08:05 I'm not aware of f-e-k issues 15:08:07 kparal: yeah, something needs to change 15:08:41 either we need to start gating rawhide composes soon, or use a different approach until that happens :) 15:08:57 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 not sure, but f26 composes had many issues over the last months 15:09:26 many of them not related to could-init 15:09:34 even systemd was completely broken 15:09:51 i mean that the ones that actually composed would fail to allow login due to a cloud-init issue 15:10:08 it's possible 15:10:12 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 but that is a topic for another day 15:11:15 any other questions or comments? 15:11:32 nope 15:11:36 tflink: jskladan tried to solve that 15:11:55 we had proof of concept of building images using openQA 15:12:07 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 #topic Documentation 15:13:42 I keep putting this as an agenda item and then neglect to follow up on it :-/ 15:14:28 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 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 https://qa.fedoraproject.org/docs/libtaskotron/latest/ 15:16:08 that's about all I had on this. nice and quick :) 15:16:09 is dist-git namespace ready and do we have some guinea pig tasks? 15:16:42 mostly, yes. the conclusion seems to be just do something and if it needs to change, it can change 15:16:43 except for dockerautotest, that's one I know about 15:17:04 pingou has volunteered to be a guinea pig with the pagure package 15:17:11 great 15:17:21 I think that the modularity folks have some tests for sed 15:17:37 well I wrote a "test suite" for gzip for last flock :) 15:17:41 I can put it in :) 15:17:44 sounds good 15:18:07 huh, i forgot to put the new topic in 15:18:12 #topic Making taskotron images public 15:18:15 whoops 15:18:34 that's fine, that's all I wanted to ask wrt documentation 15:18:46 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 and as I type this, I remember why that wouldn't have worked anyways 15:19:58 we modify it before compressing, iirc 15:20:04 what an auspicious start to the week 15:20:04 yum repos 15:20:30 the production images have hardcoded values for hosts, I think 15:20:34 or did we get rid of that? 15:21:31 I don't know, but the public ones need to have the standard yum repos files 15:21:41 so either we modify the internal ones or the public ones 15:22:29 (or standard hosts files, whatever) 15:22:32 * tflink needs to do some more homework on the details here 15:22:54 jskladan should be able to help, once he's around 15:23:09 I was wondering if anyone had other suggestions on where to host the images 15:23:22 since the disk on qa-prod01 is not enough to process images 15:23:57 client-hosts have lots of space 15:24:54 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 anyone? bueller? 15:27:35 * tflink takes that as a no, moves on 15:27:45 #topic Dist-Git Task Storage 15:28:39 so, this one has been kicking around for way too long 15:29:19 long story short, I'd like to get this enabled in at least dev this week 15:29:39 and potentially listening to koji.stg 15:30:10 so, what exactly is this? 15:30:19 what exactly is what? 15:30:25 what would be enabled? 15:30:53 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 ok 15:33:14 any huge objections? 15:33:52 no objections here 15:34:28 nope 15:34:58 cool, I'll send out emails once this is enabled in dev 15:35:09 which reminds me of one last (hopefully quick) topic 15:35:16 #topic usage of taskotron-dev 15:36:04 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 I just wanted to mention it again and see if there were any objections 15:37:10 sounds good to me 15:37:12 does it mean it will deviate from develop head, or be closer to it? 15:37:13 what kinds of things currently go into -dev? 15:37:40 dev branch of taskotron? or dev branch of any additions? 15:37:52 kparal: for the moment, it would probably deviate until all the changes made it back into develop 15:37:52 so when I finish this trigger, it'll go to dev first? 15:38:02 roshi: the taskotron-dev deployment 15:38:12 roshi: yep 15:38:38 I wasn't sure what all comprised a "deployment" 15:39:04 an entire setup of trigger, master, client-host, resultsdb, resultsdb_frontend and execdb 15:39:23 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 or test a new patch or whatever 15:40:10 i.e. new testcloud last week 15:40:18 s/i.e./e.g. 15:40:19 gotcha 15:40:34 * roshi always gets those two confused (i.e.,e.g.) 15:40:42 so atm I'm going to consult tflink every time until cancelled :) 15:41:47 any thoughts on how to keep in sync on this? 15:42:22 other thoughts, rather 15:42:43 * roshi has none 15:43:36 for the short term, this'll work but at some point, I think we'll want to find something different 15:43:45 not really. if this is a long-term plan, maybe we can deploy it elsewhere and re-use the buildbot workers? 15:44:12 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 I'm hoping it isn't a long term plan 15:44:41 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 having a bus number of 1 is never a good idea 15:44:53 (and don't add it to nagios. Then I might come and chase you down) 15:45:07 i don't think that dev is in nagios 15:45:13 qa11 is, though 15:46:23 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 let me know objections come up, though 15:46:50 we will need to figure out a better solution if this carries on 15:46:56 but that brings us to 15:46:59 #topic Open Floor 15:47:10 any other topics to cover that didn't get mentioned above? 15:47:21 nothing from me 15:47:26 none here 15:48:04 nope 15:48:10 ok, sounds like we can end with 12 minutes to spare 15:48:15 thanks for coming, everyone 15:48:19 * tflink will send out minutes shortly 15:48:22 #endmeeting