15:00:06 #startmeeting fedora-qadevel 15:00:06 Meeting started Mon Jan 15 15:00:06 2018 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:06 The meeting name has been set to 'fedora-qadevel' 15:00:06 #topic roll call 15:00:13 * kparal is here 15:00:21 #chair kparal lbrabec 15:00:22 Current chairs: kparal lbrabec tflink 15:00:37 * lbrabec is here 15:01:29 * tflink is hoping that a josef is going to show up 15:02:07 #chair jskladan 15:02:07 Current chairs: jskladan kparal lbrabec tflink 15:02:08 * jskladan a josef joins 15:02:29 (the josef is smelling glue right now, though...) 15:02:38 cool, lets get this party started 15:03:22 https://cdn.meme.am/instances/500x/67493334/looks-like-i-picked-the-wrong-week-to-stop-sniffing-glue.jpg 15:03:39 #topic Announcements and Information 15:03:59 #info taskotron production redeployed - tflink 15:03:59 #info phabricator is dead - tflink 15:04:00 #info fixed artifacts not accessible on taskotron-dev -- kparal 15:04:00 #info converted task-abicheck and task-python-versions to ansiblized taskotron -- kparal 15:04:15 do folks have anything to add? 15:04:16 Phabricator is dead! All hail the Phabricator! 15:04:32 I still need to remove the dns entries but I should be able to get that done today 15:04:38 long live phabricator 15:04:53 err, rest it peace 15:04:55 I also forgot to backup the docs before I blew the vm away so those will need to be regenerated 15:04:57 *in 15:05:41 no questions 15:05:43 if there's nothing to add, any questions/comments? 15:06:37 * tflink takes that as a "no" 15:06:49 #topic Ansiblize Branch Progress 15:07:17 I think that most of this was covered earlier but anything else to add? 15:07:29 4 tasks converted, I'm working on rpmdeplint now 15:07:34 cool 15:07:36 it's going to be a bit more difficult 15:08:35 that's all from me, unless you have some specific questions 15:08:41 does that indicate that we might want/need custom modules to deal with parts of rpmdeplint? 15:09:15 that would be great, but for the moment, I simply write a python script, import libtaskotron and call the directives directly 15:09:44 in the future, it would be nice to convert at least some of those directive to ansible modules and distribute them in fedora 15:09:48 did I ever post the custom modules I wrote? 15:09:55 this is going to be embarrassing if I didn't 15:10:02 there's a koji module bundled in libtaskotron 15:10:07 I don't know of anything else 15:10:15 I think that's the only one I finished 15:10:35 either way, it needs to be packaged and available in fedora, which is somewhat more work 15:10:43 it sounds like this is going to be a good conversation to have once the porting is done 15:10:56 sure, we can talk about this as the next step 15:11:06 since I wasn't sure what modules would even be needed 15:11:49 any other questions/comments here? 15:12:11 nope 15:12:19 ok, moving on 15:12:23 #topic Cloud Plans 15:12:45 Not much of an update here - I started working on generating images for openstack again last week but didn't get very far 15:13:24 * kparal is looking forward to it 15:13:45 I don't remember if I've said this yet but moving to openstack will solve a good chunk of our non-x86 arch issues 15:14:09 as it already has ppc instances available and will have aarch64 instances available before long 15:14:18 cool! 15:14:40 my current plan is to generate images and probably keep them on the box we were using for phab 15:14:55 and use rsync to keep the client hosts up to date for now 15:16:05 I'm hoping that will solve the publicly available image problem while we're at it 15:16:32 other than that, I don't have much of an update here - was working on other stuff last week 15:16:38 any questions/comments? 15:16:43 nope, thanks for update 15:17:17 ok, moving on to a topic that I remembered about an hour ago and isn't on the agenda :) 15:17:29 #topic ResultsDB Deployment and Hosting 15:17:59 one of the things that came up during the production redeployment is that there are new things relying on resultsdb 15:18:26 specifically, greenwave is the brand new thing but AFAIK, bodhi is relying on resultsdb more than it used to 15:19:12 one of the questions asked when the redeployment happened was if we could build the new instance and just change dns to resolve to the second host instead of destroying and rebuilding during an outage 15:19:51 another question I have is whether it might be wise for us to move production resultsdb over to RHEL instead of Fedora 15:20:20 tflink: so we don't need to upgrade the machine every six months? 15:20:28 or for any other benefits? 15:20:48 decreased downtime, moving it closer to other infra services 15:21:27 if we can do the "hot swap" upgrade method, I'm not sure it's so much of an issue, though 15:21:54 /win 19 15:22:12 also, are there any reasonable options to start doing HA for resultsdb? 15:22:39 I suspect that having multiple instances with a load balancer would work without issue 15:22:46 * jskladan has no experience with Hight Availability whatsoever 15:23:43 resultsdb seems to be on the path to be a rather critical piece of infra for Fedora, I think it'd be wise to start exploring this sooner than later :) 15:23:55 hence the topic 15:23:59 are we talking multiple 'frontends' (as in the resultsdb wsgi apps) with single DB backend, or multiple DB backends too? 15:24:16 multiple frontends to start 15:24:42 IIRC, the change to multiple db backends is a very non-trivial process 15:25:04 tflink: I would think so, sounds like real-time data replication :) 15:26:05 but that's outside my experience so it'd likely be good to talk to others 15:26:15 * jskladan agrees 15:26:36 I don't know what happened with the postgres bdr proposal that infra had 15:26:54 * tflink makes note to follow up on that and ask questions about HA etc. 15:27:52 also, having a load balancer in front of the wsgi apps would let us do upgrades with little to no downtime 15:28:00 yup 15:28:06 any other questions/comments on this? 15:28:41 * tflink takes that as a no 15:28:44 do you know if there's already something like that in place (koji/bodhi would be my candidates) for other apps in infra, so we can get "creatively insipired"? 15:28:44 #topic Tasking 15:28:50 sorry 15:28:52 #undo 15:28:52 Removing item from minutes: 15:29:03 jskladan: blockerbugs is HA 15:29:21 that would be my first thought 15:29:25 tflink: cool, that makes it even simpler, I guess 15:30:06 it's mostly a matter of getting multiple instances, setting up haproxy and reworking the proxy settings so that the traffic flows the way it's supposed to 15:30:18 makes sense 15:30:40 it'll require some downtime to set up but I think it'd be a worthwhile thing to do 15:30:50 * jskladan agrees 15:31:02 * tflink will talk to infra about it 15:31:09 anything else? 15:31:24 nope 15:31:39 cccccccdbcihvffhghuvrjntljvvkfjkjttcfeutdfld 15:31:43 *sigh... 15:31:45 actually, this is kinda related - did we ever figure out more details on what kind of scripts would be required for us to decommission most of taskotron-stg? 15:31:52 ooh, an OTP 15:32:19 * jskladan should really re-configure that token to not send enter... 15:32:44 eh, I think we've all done it at some point :) 15:33:15 adamw hasn't gotten very loud about the box I promised him but that could change :) 15:33:23 loud/pester-y 15:33:44 I haven't done any work on looking at taskotron-stg mock replacement 15:34:05 so I believe the answer is no 15:34:12 unless someone else did 15:34:16 that's what I thought but figured I would ask 15:34:32 * tflink takes that as a "no" 15:34:40 moving on to the next topic 15:34:43 #topic Tasking 15:34:53 Do folks have things to work on? 15:36:04 I'm converting the remaining tasks 15:36:14 or need/want tasks? 15:36:21 kparal: sounds good 15:36:35 has taskotron-dev been behaving for the most part? 15:36:56 I'm going to be working on code to make passing a structured file with arg-data from trigger to the task - talked with kparal last week, and it seems like the sooner we can do this, the better 15:37:17 but if there's something else I could help with, shoot! 15:37:23 did I miss the conversation/ticket(s) there? 15:37:39 -dev has been working fine so far 15:38:05 tflik - this is something we were discussin on and off for quite some time (since the "git commit" item type IIRC) 15:38:58 yeah, I recall talking about it in the past but wasn't quite sure what brought the topic up recently 15:39:22 kparal's recent experience with converting the tasks :) 15:39:31 it's kind of hard to split triplets of information (like the git commit item) in ansible playbook 15:39:38 without writing a custom module 15:39:53 so that's why we really need structured input information soon 15:40:21 jskladan can tell, according to his task-taskotron-ci 15:40:58 ok - do you have any implementation details/plans? 15:41:35 I don't, really 15:41:48 I'm hoping jskladan has :) 15:41:55 * jskladan plans to have a look at buildbot's capabilities 15:42:11 hopefully it will be able to pass a file down to the worker 15:42:24 what about generating a file on task invocation? 15:43:01 ie - convert the cli args to a file prior to starting any ansible execution 15:43:21 * tflink realizes that would only solve part of the problem 15:43:42 the problem that having a file with data would solve, rather 15:45:01 we can continue this conversation later, I guess 15:45:21 tflink: generating a file using a ShellCommand and some echo magic was my backup plan - depending on whether there is no more elegant way 15:46:02 I suppose that would probably be easier 15:47:14 lbrabec: do you have enough tasks to keep you busy? 15:47:19 and for executor - my plan is to just add a "--file" (or something like that) parameter, which will load the file (yaml/json) and override/add more stuff to the 'arg data', so we can pass it to the ansible using the means already in place 15:47:56 I guess so, there's still plenty of TODOs and FIXMEs in the code 15:48:14 lbrabec: anything in particular that you're planning to look at? 15:49:05 * jskladan has to go afk for a moment 15:49:19 mainly the SI parts 15:49:57 the parts that can/will run SI stuff without the need for any porting? 15:50:09 yep 15:50:58 cool. I'm looking forward to hearing what all (if anything) is still needed to make that happen 15:51:29 do you think you could get that list together this week? 15:51:48 it'll be a good topic for conversation around qecamp/devconf 15:51:51 sure 15:52:02 great, thanks 15:52:11 I think this brings us to ... 15:52:15 #topic Open Floor 15:52:37 is there anything that folks want to bring up before closing the meeting out? 15:52:55 nothing here 15:53:01 nope 15:53:54 ok, I'll end the meeting momentarily, then 15:54:00 thanks for coming, everyone 15:54:04 thanks 15:54:08 * tflink will send out minutes shortly 15:54:11 #endmeeting