15:03:51 #startmeeting fedora-qadevel 15:03:51 Meeting started Mon Mar 16 15:03:51 2015 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:51 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:51 #meetingname fedora-qadevel 15:03:52 #topic Role Call 15:03:52 The meeting name has been set to 'fedora-qadevel' 15:04:06 #chair jskladan kparal mkrizek roshi 15:04:06 Current chairs: jskladan kparal mkrizek roshi tflink 15:04:09 * jskladan is here 15:04:11 * mkrizek is here 15:04:13 * kparal is here 15:04:15 * roshi is here 15:05:28 cool, let's get this party started 15:05:39 who wants to go first with status? 15:05:53 #topic ExecDB 15:06:04 #info ExecDB is now more defensive in parsing Taskbot's push notifications 15:06:04 #info ExecDB is IMHO ready to be deployed 15:06:17 * kparal cheers 15:06:40 comments/questions? If not, I'll move to OpenQA update, and that will be all from me 15:07:04 no specific questions here 15:07:05 no more corner cases found? 15:07:50 tflink: nope, the only corner-case is the re-scheduling, but that IMHO works as expected now, and will need more work in the future anyway 15:08:12 yeah, I can think of other stuff that will need work in the future but nothing that would block deployment 15:08:39 sounds good - we can talk about deployment in the next section 15:08:42 ook 15:08:57 * danofsatx is here 15:09:06 #topic OpenQA 15:09:06 #info OpenQA looks good so far - some occasional quirks, but nothing too serious 15:09:06 #info covered testcases are to be found here https://bitbucket.org/rajcze/openqa_fedora_tools/src/master/PhaseSeparation.md 15:09:06 #info jsedlak is now working on covering FedUp testcases 15:09:51 are there any significant holes in the openqa coverage? 15:10:05 well, holes that we want to cover for beta 15:10:32 Just the Upgrade testcases 15:10:46 cool 15:11:01 the rest (of what we think is OpenQA-able) is mostly covered 15:11:52 #info most of the work-to-be-done on OpenQA will be Upgrade & NFS(repos, kickstarts, ...)-related 15:12:13 that's about it from me, then 15:12:20 thanks 15:12:25 who wants to go next? 15:12:32 #topic kparal status report 15:12:32 #topic Taskotron Artifacts 15:12:35 :) 15:12:39 you go 15:12:50 ok 15:12:57 #info artifacs have been running on dev for a while now, no issues (that hasn't been fixed) has been seen 15:13:07 #info there is a dir for each day where artifacts of that day are put to speed up loading of taskotron.fp.o/artifacts/ 15:13:25 that's it for artifacts, any questions? 15:14:01 I'd like to deploy artifacts once execdb deployment is done since they are related (uuid) 15:14:22 did you get the date directory part deployed? 15:14:26 * tflink doesn't see it on dev 15:14:35 I did 15:14:52 http://taskotron-dev.fedoraproject.org/artifacts/20150316/ 15:15:14 ah, I scrolled past it 15:15:28 yeah, client27 messed it up a little 15:15:49 how much stuff is still not in git? 15:15:58 wasn't there a required patch for trigger? 15:16:20 yeah, but that is part of execdb patch, so afaik it's in git 15:16:25 ah, ok 15:16:35 mkrizek: looks good 15:16:58 cool, looks good 15:17:10 ok, moving on to 15:17:12 #topic Disposable Clients Remote Execution 15:17:23 #info now working on evaluation communication methods between task initiator and executor - paramiko or ansible are subjects of evaluation 15:17:36 I just started with it today, so that's about it 15:17:52 hopefully paramiko will work 15:18:21 anything else? 15:18:25 nope 15:18:40 kparal: want to go next? 15:18:44 #topic kparal status report 15:18:53 #info fixed mock crashes for single-arch packages 15:18:53 #link https://phab.qadevel.cloud.fedoraproject.org/D303 15:19:01 this time hopefully for good 15:19:09 #info helped out with implementing the koji download cache, review still pending, as well as submitting unit tests 15:19:09 #link https://phab.qadevel.cloud.fedoraproject.org/D266 15:19:19 reviewers welcome 15:19:32 #info still haven't filed a bug about gtk spinner performance issue, planning to do it soon. it's slowing down openqa execution (and manual testing) considerably. (just the main installation time goes from 5 minutes to 15 minutes on my otherwise almost idle laptop, in my testing). 15:19:59 that's all on my side 15:20:19 cool, sounds good 15:20:38 #topic tflink status report 15:20:50 #info updated systems, seem to still be having problems with trigger :-/ 15:20:50 #info still watching for bad depcheck failures 15:20:50 #info working on tickets for disposable clients 15:21:22 not as much as I would like, but that's about it 15:21:30 still no depcheck failures till the day we enabled the debug info? 15:22:06 there's been one but it was the samba critical security fix and by the time I noticed it, it was already in stable 15:22:07 *since 15:22:34 ok. I guess no depcheck failures is also good news :) 15:22:44 or almost none 15:23:05 there's one potential from over the weekend but I haven't looked at it in detail yet 15:24:05 roshi: did you have anything? 15:24:48 * tflink assumes not 15:24:55 #topic Tasking/Planning 15:25:07 there's a few things to cover, I think 15:25:32 it sounds like both artifacts and execdb are ready to start merging in and deploying 15:25:49 * tflink proposes that we get that done and roll it out as we migrate to f21 15:26:11 sounds good to me 15:26:37 mkrizek, jskladan: how long do you think it'd take to get your code reviewed and into devel? 15:27:08 my code is already in devel 15:27:18 *shrugs* let me check the amount of code not in devel 15:27:47 I suppose a better question would have been how long it'd take to get any code not in devel reviewed and committed 15:27:55 but that's the question you're answering anyways :) 15:28:10 is anyone interested in helping redeploy taskotron? 15:28:50 I don't - just watching :) 15:28:58 what facets of "redeploy" need help? 15:29:09 trigger is in develop; libtaskotron is in develop; resutlsdb bits are also in develop 15:29:18 how much is that work? I thought ansible would do most of the work? 15:29:51 so, it seems that unless I'm missing something, all the ExecDB related bits are already in the develop branches of the respective projects 15:29:57 there are a couple of manual things that need to happen but it's mostly running the playbooks and making sure that everything is still working with f21 15:30:10 I can help with that 15:30:21 #info artifacts and execdb should both be feature complete and ready for deployment 15:31:22 mkrizek, danofsatx: are you free tomorrow to start working on redeploying dev? 15:31:40 yep 15:31:56 I'm afraid to commit - my $dayjob tends to intrude. 15:32:02 * tflink doesn't think that we have enough time to get everything done in production but we could probably get dev/stg done before beta free 15:32:37 danofsatx: would a different time work better for you? 15:32:49 s/beta free/beta freeze 15:33:12 we also need to ansible-ize execdb 15:33:16 to be honest, no. I can only be trusted right now with things that aren't important. 15:33:34 unless josef has already got that mostly done 15:33:53 danofsatx: no worries, should I just ping you when we're about to start to see if you're free enough to help? 15:34:23 that might work. I'm trying to decipher many differnt tools and learn python right now, but I could always use a break. 15:35:36 ok, sounds like the start of a plan: get dev redeployed as f21, get execdb ansible-ized and continue with the testing 15:36:05 one other bit is that we probably want to re-visit the partition layout of the taskotron master 15:36:08 tflink: well, anslible-izing execdb is done in my private branch of the "all-in-one" ansible scripts 15:36:23 but there are some hacks here and there 15:36:33 and stuff is mostly copied from other places anyway... 15:36:38 * tflink would prefer to put artifacts on a separate partition to avoid running out of disk 15:36:57 (hacks are present to overcome the need for changing the ansible-infra stuff) 15:37:11 jskladan: I assume that it'd be better than starting from scratch, though 15:37:50 tflink: so do I, especially if one will have the possibility to change stuff in the infra's ansible scripts 15:38:45 jskladan: can you post your patches somewhere or take on getting them into infra's repo? 15:40:03 I'll upload the contents of my all-in-one into a branch 15:40:10 if that's enough 15:40:28 yeah, that should be 15:40:34 branch of the all-in-one repo? 15:40:39 yes 15:41:03 and I can then, of course, make the diffs for fedora-infra 15:41:06 cool, sounds good 15:41:21 if you point me in the right direction with places for reviews etc 15:41:41 there isn't really a place for reviews for the infra ansible repo 15:41:54 just pull requests then? 15:42:06 (we can discuss this off-meeting maybe?) 15:42:35 we could do the same thing that mkrizek did for some buildmaster changes (artifacts stuff, IIRC) 15:42:44 ie, phabricator can do reviews without knowing about the repo 15:42:51 #action jskladan to ansible-ize execdb 15:42:53 but yeah, can figure it out offline 15:42:55 ook 15:43:56 I figure it makes sense to get the execdb and artifacts stuff released before we start making changes for disposable clients in the develop branch 15:46:13 I'm not sure how much more can be done with disposable clients before we put at least a skeleton into develop 15:47:08 is anyone interested in investigating testcloud? 15:47:24 https://phab.qadevel.cloud.fedoraproject.org/T407 15:47:34 * danofsatx is looking 15:47:46 I am, I just didn't have time to play with it yet 15:47:48 I'll prioritize it 15:47:51 investigating may not be the best term here 15:48:30 it's mostly looking through the PoC code and getting a list of stuff that we'll need from/for testcloud 15:48:53 I've added testCloud as a project 15:48:54 https://phab.qadevel.cloud.fedoraproject.org/project/view/20/ 15:48:59 oh, code. in that case, I'll just watch from the sidelines. 15:49:07 and broke out some known issues there 15:49:14 since there aren't any real alternatives and it's pretty close to what we need - I suspect that it'll end up being easier to work with testcloud than to roll our own 15:49:27 this week I hope to get my local branch cleaned up and pushed to gh so others can work on it 15:49:57 it's in a state of, uh, nasty looking since I kinda stopped working on it mid-way through for other stuff 15:51:54 that's the concrete stuff that I had for today - I suspect that the execdb/artifacts deployment isn't going to last 2 weeks, though and there will be other conversations around tasks before the next planning-edition meeting 15:52:00 * kparal grabs the ticket 15:52:51 any other items/topics before open floor? 15:53:43 * roshi has none 15:53:43 #topic Open Floor 15:53:46 I sat in on the fedora-security meeting last week, and came up with an idea. They need some way to track the security bugs, and our blockerbugs app fits the requirements perfectly. They also like the idea of setting up QA-style procedures for releases, but only for security related items. 15:54:31 I was wondering how much work it would take to set up a blockerbugs instance for the security folks, and whether I'd be capable of doing it myself. 15:54:57 danofsatx: depends on what their process is, I think 15:55:12 well, they don't really have any yet. that was the focus of their meeting. 15:55:43 blockerbugs is pretty purpose-specific and hard-coded for the release blocker process (whiteboard status indicators etc.) 15:56:07 setting up another instance shouldn't be too bad, though 15:56:32 exactly - the bugs they track are CVE and others. I thought they could use the white board field, and/or set up tracker bugs. 15:57:25 I suspect that some tweaking of the code would be required, at least 15:57:57 yeah, I understand that - like the strings it goes looking for and such. I already glanced at the code, and *think* I understand it. 15:58:31 it was fairly well written and documented code - kudos to y'all that wrote it. 15:58:48 s/fairly/very 15:59:03 I'm not against the idea of making it more general, there's already a request to make it work for secarch 15:59:23 not sure how many cycles we have to do that, though 16:00:02 Well, I know I can't generalize it. But, I think I can at least fork it and change what needs changed for the specific purpose at hand. 16:00:44 maybe through my efforts, it will reveal the details of what needs modified to generalize it? 16:01:00 yeah, I figure the first step would be to figure out what changes would be needed 16:02:57 danofsatx: once we know what would need to change, we can start evaluating where to go from there 16:03:04 anything else for open floor? 16:03:09 nope 16:03:09 since we're 3 minutes over 16:03:14 OK, I'll start looking at something I can put together as a PoC for security, and ping y'all when I think it's ready. 16:03:27 sounds good to me 16:03:59 blocker review going on now as well :) 16:04:58 I'm done. lite the fuse tflink 16:05:10 thanks for coming, everyone 16:05:14 * tflink will send out minutes shortly 16:05:17 #endmeeting