15:01:14 #startmeeting fedoraqa-devel 15:01:14 Meeting started Mon Mar 2 15:01:14 2015 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:21 #meetingname fedoraqa-devel 15:01:21 The meeting name has been set to 'fedoraqa-devel' 15:01:27 #topic short role call 15:01:33 * kparal is here 15:01:45 * tflink almost typed that as "roll call" by accident, must be monday morning :) 15:02:51 * kparal pick the role of a dwarven warrior 15:02:57 *picks 15:03:12 * jskladan is here 15:03:27 * tflink picks the role of mage :) 15:03:58 that means I destroy things and you create illusions 15:04:31 * tflink attempts to conjure up more people who should be here 15:04:42 mkrizek is sick 15:04:51 I think he will not come 15:04:55 ah, that would explain him being offline 15:05:25 jskladan: do you know if lbrabec or jsedlak are planning to come? 15:05:31 I forgot to ask them, once again 15:05:37 let's get started then, since that accounts for everyone I was expecting 15:05:40 I'm almost certain that they won't be showing up 15:05:55 I'll try to remember next time 15:05:58 #info trying new meeting format for today 15:06:19 #topic status updates 15:06:24 who wants to go first? 15:06:33 #topic ExecDB 15:06:40 #info ExecDB and all the parts are in the Git of the respective projects 15:06:46 #info "dev" instance at taskotron-demo looks fine so far 15:06:47 no topic changes? 15:06:47 whoops 15:06:52 #chair jskladan kparal 15:06:52 Current chairs: jskladan kparal tflink 15:06:53 my bad 15:06:58 #topic ExecDB 15:07:05 #info ExecDB and all the parts are in the Git of the respective projects 15:07:09 #info "dev" instance at taskotron-demo looks fine so far 15:07:31 I do not have any ExecDB related tasks on my plate, so that is about it 15:07:35 yeah, looks good so far to me 15:08:05 at some point, we should figure out what is "good enough" for an initial production deployment 15:08:54 * jskladan would be inclined to say that "this" is good enough 15:09:08 http://taskotron-demo.cloud.fedoraproject.org/execdb takes quite a long time to load, we will need paging 15:09:23 * tflink is a bit worried about the corner case of repeated executions 15:09:41 #task jskladan to add paging in execdb 15:10:10 tflink: apart of the "mess" it creates in the visualization, I do not really worry that much 15:10:11 thanks 15:10:15 but I'm not sure it's worth fixing 100% right now 15:10:34 jskladan: yeah, we'd still have data in resultsdb, so it's not a huge problem 15:10:42 yup 15:10:43 it's not that common 15:10:56 the only problem that I see is that we miss the link to the "first" execution in the ExecDB 15:11:01 and the mess in the steps 15:11:35 but the link to previous executions can be found in resultsdb if we really need it 15:11:50 #task jskladan to play around with spoofing ExecDB with messages - clean-up the multiple-of-the-same-steps mess 15:11:59 * tflink wonders how long we want to leave it in -demo before deploying to -dev 15:12:05 tflink: no, not really, because both of the jobs will point to the same ExecDB's job 15:12:11 (since it has the same UUID) 15:12:44 and I'm not sure if Taskbot keeps reference 15:12:50 for re-scheduled jobs 15:12:56 won't the result in resultsdb still point to raw log files? 15:13:09 ah, that is true 15:13:18 I thought we're talking about the jobs "ref" link 15:13:44 #task jskladan to check whether Taskbot keeps links between re-scheduled jobs 15:13:53 * tflink makes note that we should probably get rid of the "taskbot" references in resultsdb_frontend 15:14:28 ok, anything else for execdb? 15:14:33 nope 15:14:44 kparal: you want to go next? 15:14:47 ok 15:15:14 I don't have it coupled by projects, I just created a wall of text related to my person in general 15:15:35 yeah, I wasn't sure if per-project would work well long term :) 15:15:36 such a narcissist ;) 15:15:55 #topic kparal-the-narcissist's summary 15:16:04 #info reviewed a lot of smaller patches 15:16:09 #info talked to rpmgrill folks who would like to have the tool running inside taskotron for all new koji builds. Clarified some requirements, explained what we currently can and cannot support. Some rpmgrill adjustments expected. Another meeting in a week. 15:16:42 if you want to stop me and comment on something, just print a dot or something 15:16:52 #info pushed upgradepath changes for creating per-build and per-update log files as artifacts. It's in the newly created `develop` branch (now the default branch for the task). 15:16:52 #link https://phab.qadevel.cloud.fedoraproject.org/D282 15:17:06 did we get that deployed on -dev? 15:17:22 I believe mkrizek did, but I'm not 100% sure 15:17:29 I can quickly check 15:17:58 looks like 15:18:14 the hash in http://taskotron-dev.fedoraproject.org/taskmaster//builders/x86_64/builds/78062 matches develop's head 15:18:33 the answer is yes 15:18:45 you were faster 15:18:58 http://taskotron-dev.fedoraproject.org/taskmaster//builders/x86_64/builds/78062 15:19:02 is an example 15:19:58 I'm not sure how to reach the artifacts now 15:20:14 not sure I understand what you mean by "reach the artifacts" 15:20:36 found it: http://taskotron-dev.fedoraproject.org/artifacts/4913f378-c0ea-11e4-8525-5254003d4660/task_output/ 15:20:38 oh, I posted the wrong link 15:21:00 you need to go to http://taskotron-dev.fedoraproject.org/artifacts/ and find the uuid hash 15:21:02 yeah, it's in http://taskotron-dev.fedoraproject.org/artifacts/ 15:21:30 ok 15:21:55 anything else? 15:21:58 #info created a tmpfiles.d config file. Useful in development environments. Install this into /etc/tmpfiles.d and taskotron-related directories will be pruned regularly. This is especially useful if you run tasks like depcheck from time to time on your local machine, because it generates gigabytes of data in a single run. 15:21:58 #link https://phab.qadevel.cloud.fedoraproject.org/D298 15:22:18 #info moved all existing Taskotron-related documents under a common root in Phab. This will allow us to create Herald rules watching all edits under this document root. I'll send out an email once I verify it works correctly. 15:22:18 #link https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/ 15:22:42 this is actually weird, we tested it with jskladan a bit today and I don't seem to get _any_ emails, even from subscribed documents 15:23:00 so it doesn't work, but I have no idea why 15:23:06 fun 15:23:20 will test it more 15:23:27 #info now working on a patch for the root cause of task-depcheck failures for single-arch packages 15:23:27 #link https://phab.qadevel.cloud.fedoraproject.org/T351 15:23:41 #info also wanting to have a look at some older pending patches, but I can just neglect it and start working on some important future-plan task instead, if needed 15:23:54 that's all I have prepared 15:24:24 kparal: cool, thanks 15:24:57 kparal: which older patches did you have in mind? 15:25:39 jskladan asked me to review https://phab.qadevel.cloud.fedoraproject.org/D266 15:25:58 yeah, I've got that on my TODO list as well 15:26:19 anything else? 15:26:24 that's all 15:26:33 I suppose it's my turn 15:26:51 #topic status summary - tflink 15:27:03 outside of code reviews and other related stuff 15:27:17 #info got taskotron.stg working externally for the first time in about a month 15:27:31 finally fixed? great 15:27:36 #info updated,broke and fixed phabricator on qadevel 15:27:43 :) 15:27:50 #info still watching for bad depcheck failures, haven't seen any fast enough to capture 15:28:10 #info writing design docs and some tickets for disposable clients, still ongoing 15:28:42 first design doc is: https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/planning/disposable_clients_high_level_design/ 15:29:19 that's about it, the rest will be covered in planning/discussion 15:29:23 #link https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/planning/disposable_clients_high_level_design/ 15:29:50 * tflink thinks that meetbot automagically #links inline http links 15:29:59 but explicit is good :) 15:30:24 if something isn't clear in that doc, let me know 15:30:42 I tried thinking of pictures that could help and couldn't think of anything that would help 15:31:02 any other questions/comments? 15:31:21 :) nope 15:31:32 #topic other status 15:31:52 #info task artifacts storage deployed to dev: http://taskotron-dev.fedoraproject.org/artifacts/ 15:32:24 #info more details on that at another time, is an initial feature 15:32:29 which brings us on to 15:32:38 #topic tasking/planning 15:32:58 one of the easy ones to talk about is our infrastructure 15:33:14 #info most of taskotron's infrastructure is running on F20, which will go EOL soon, need to migrate to something different 15:33:33 * tflink mentioned this to both mkrizek and jskladan last week, talked to infra a little as well 15:33:49 do you expect any issues when upgrading to F21? 15:34:04 no, but the subquestion is whether we migrate to el7 15:34:07 kparal: the thing is, whether not to go for el7 15:34:32 I think that mkrizek's suggestion of migrating to f21 for now and putting off the el7 question for a bit makes the most sense 15:34:51 * kparal doesn't have any particular opinion 15:34:59 the migration won't be trivial - I don't think it'll be too painful but it will require getting buildbot packages for el7 15:35:25 I'm not really necessarily against either, but since the new Taskbot is currently for packaged for F21, and we don't have packages for el7, I'd rathe go for F21 15:35:29 the other question is how much we'd be slowed by having to test/dev on el7 instead of fedora since we're all using fedora machines for dev 15:35:36 * jskladan has slow typing skills today :/ 15:36:02 so, I'd like to redeploy -dev on F21 after alpha is released 15:36:29 we can revisit the el7 question when we're looking to push the disposable client feature to stg/production 15:36:56 +1 15:37:10 sounds good 15:37:44 #info current plan is to start migrating to F21 after F22 alpha freeze is over, revisit the question of whether to migrate to el7 at a later date (probably when we're looking to deploy disposable clients in stg) 15:38:48 * tflink will try to find help for that, will be a good learning experience for someone else to become more familiar with how things are deployed 15:39:16 any other topics to go through? 15:39:33 unless there are other comments/concerns, moving on to the bigger topic of disposable clients 15:40:15 #topic disposable clients planning/tasking/discussion 15:40:30 I've started reworking and adding tickets to the main feature tracker 15:40:34 #link https://phab.qadevel.cloud.fedoraproject.org/T298 15:42:16 #info high level design doc at https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/planning/disposable_clients_high_level_design/ 15:42:49 I think that the biggest units of functionality in there are going to be VM management and remote execution 15:43:13 I'm assigned to T300, so I should have a look at that. alternatively, T407 or T408 sound as a good start. any priorities here? 15:43:17 hopefully, we'll be able to utilize testCloud (or whatever it's renamed to) 15:43:58 kparal: T300 has some implementation in the PoC code I wrote for no-cloud disposable clients 15:44:13 great 15:44:36 * tflink is thinking that it makes sense to specialize a little for now 15:45:11 ie, have folks focus on somewhat isolated areas of the process - VM management, task execution, image handling 15:45:51 I'd like to see T407 handled soon-ish so we can get started working with roshi on any required features missing from testcloud 15:47:27 ok, so I'll grab it and look at it 15:47:37 the other high priority stuff is the tickets I was about to write before the meeting: subtasks of T415 15:48:39 part of which will be figuring out if the PoC code I wrote is worth trying to integrate into libtaskotron 15:50:49 should we distribute the tickets now? 15:51:52 we can start 15:52:07 one of the issues that can be worked on is communication with the VMs 15:52:29 a big problem in the PoC is that ssh doesn't natively have exit codes 15:52:47 so detecting problems in execution is not incredibly straightforward 15:53:02 we would need to write a patch for paramiko 15:53:06 I ignored this in the PoC but I don't think it can be ignored going foward 15:53:26 I don't think that paramiko needs a patch - it's just an interface to ssh 15:53:43 I showed you that it works in bash with ssh itself 15:53:55 ssh machine 'false' 15:53:59 returns 1 15:54:25 so we need to investigate more, maybe it's a python binding issue 15:54:53 yeah, if it makes sense to submit a patch for paramiko, I'd be OK with that 15:55:10 * tflink suspects that it would have already been done if it was simple or straightforward, though 15:55:19 that's true 15:55:50 jskladan: is there a part of this that you're particularly interested in? 15:56:10 *shrugs* I don't really have given it much thought 15:56:40 apologies for being so delinquent on getting the tasks filed 15:57:08 3 minutes left 15:57:16 jskladan: maybe look at the tasks once I get more of them filed today, we can sync up tomorrow? 15:57:32 yup, that sounds good 15:57:33 I have one further topic, very short one 15:58:02 kparal: go for it 15:58:13 #topic summer time! 15:58:16 * tflink assumes that there are no huge concerns or issues with how things are progressing? 15:58:29 oh yeah, that's coming up, isn't it 15:58:35 just to remind everyone, north america shifts to summer time this sunday 15:58:42 if I'm not mistaken 15:58:57 yeah, march 8 15:59:06 I'd like this meeting to stick to NA local time, same as with QA meeting 15:59:11 yay for moar timezone madness 15:59:23 yeah, I think that shifting with the QA meeting makes the most sense 15:59:24 so it's just something to keep on mind and maybe mention it in the next announcement 15:59:41 having a meeting at the same time as the QA meeting seems like a bad idea to me :) 15:59:46 :) 15:59:47 thanks for the reminder 16:00:05 you're welcome, I've found out today while investigating "issues" in fedocal 16:00:23 which turned out to be no issues at all, just a time shift in NA :) 16:00:44 #info next week's qadevel meeting will be at 16:00 UTC with the start of DST in NA 16:00:56 #topic open floor 16:01:04 anything quick before we wrap up for the qa meeting? 16:01:13 does this format seem to have potential? 16:01:50 I'm fine with it for the moment 16:01:50 * tflink figures it's worth trying for a couple of weeks before changing much 16:01:57 well, if it were moar status updates and less discussion, we would make in in under 30 minutes! 16:02:14 jskladan: this week it was expected to have planning involved 16:02:22 yeah, it was a planning week 16:02:28 once in a _fortnight_, don't forget :) 16:02:36 my comment was meant as a compliment, actually... 16:02:42 next week should be just status, hopefully it'll go quickly 16:02:59 qa meeting has started 16:03:19 yep 16:03:28 if there's nothing else, I'll close out the meeting 16:03:34 thanks for leading it 16:03:36 * tflink will send out minutes shortly 16:03:39 kparal: the whole meetings were supposed to be bi-weekly, when we first discussed it... don't try and fool my with your British didlydoo 16:03:40 np, thanks for coming 16:04:07 * tflink wonders if there is any obscure wording to describe every-other-week 16:04:14 anyhow, time for qa meeting 16:04:17 #endmeeting