19:01:33 #startmeeting Fedora Infrastructure Ops Daily Standup Meeting 19:01:33 Meeting started Thu Jan 9 19:01:33 2020 UTC. 19:01:33 This meeting is logged and archived in a public location. 19:01:33 The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:33 The meeting name has been set to 'fedora_infrastructure_ops_daily_standup_meeting' 19:01:33 #chair smooge nirik relrod cverna 19:01:33 #info meeting is 30 minutes MAX. At the end of 30, its stops 19:01:33 #info agenda is at https://board.net/p/fedora-infra-daily 19:01:33 Current chairs: cverna nirik relrod smooge 19:01:33 #topic Tickets needing review 19:01:47 and I just got my browser working 19:02:32 just in time. :) 19:02:43 o/ 19:02:48 .ticket 8514 19:02:49 smooge: Issue #8514: Need someone to push for the new DNS change - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/8514 19:03:07 thats done/not needed, but we need to update docs. 19:03:21 ok will fix ticket 19:03:51 well, can we quickly update the doc? 19:03:56 * nirik looks 19:04:08 pagure.issue.edit -- smooge edited the close_status and status fields of ticket fedora-infrastructure#8514 https://pagure.io/fedora-infrastructure/issue/8514 19:04:09 pagure.issue.tag.added -- smooge tagged ticket fedora-infrastructure#8514: dns https://pagure.io/fedora-infrastructure/issue/8514 19:04:10 pagure.issue.edit -- smooge edited the priority fields of ticket fedora-infrastructure#8514 https://pagure.io/fedora-infrastructure/issue/8514 19:04:11 pagure.issue.comment.added -- smooge commented on ticket fedora-infrastructure#8514: "Need someone to push for the new DNS change" https://pagure.io/fedora-infrastructure/issue/8514#comment-619999 19:04:50 nirik, I have not been able to update the docs at all lately. it has been on my 'round-tuit' to figure out why 19:06:06 i like to make DNS edits with a YOLO attitude, and then set the timeout to 86400 19:07:12 https://pagure.io/infra-docs/pull-request/177 19:07:32 .ticket 8516 19:07:33 nirik: Issue #8516: fedmsg-gateway on Python3 needs monitoring fixes - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/8516 19:07:44 what is funny is I can merge on that repo 19:07:52 which I just did 19:07:54 so, sadly this will take some digging into the bowells of fedmsg. :( 19:08:12 ewwww 19:08:17 how easy would it be to move to fedora-messaging ? 19:08:23 the bowlofeggs of fedmsg? 19:08:36 s/bowlofeggs/boweloffedmsg/ 19:08:43 is fedmsg-gateway the thing that does <--> with fedora-messaging? 19:08:49 no 19:08:54 we should have the fedmsg messages on fedora-messaging 19:09:40 I am trying to recall which thing gateway is. 19:09:51 but it's interfacing with the public 19:10:24 the goal of this monitoring is to check if an application send a message within the last X hours ? 19:10:48 if that's the case we could replace this and use fedora-messaging I guess 19:10:56 no, it's not 19:11:39 ha ok :( 19:12:01 fedmsg-gateway listens on all the proxy servers and gateways messages to/from busgateway 19:12:10 it's challenging to know what to do about it if we don't know what it is 19:12:12 I just can't recall if it's the rw one or the ro one 19:12:18 oh 19:12:18 the docs are not much help 19:12:38 is this what i get messages from if i run fedmsg-tail in my house? 19:13:07 might be yeah. 19:13:27 oh important is it for it to be monitored :P ? 19:13:29 and we want to know if it dies for external people by monitoring it on each node? 19:13:40 yeah is this mission critical? 19:14:15 I would say no, even more considering that we are asking people to switch to fedora-messaging 19:14:28 this is even maybe something we could tiurn off 19:14:32 turn* 19:14:47 and we have a thing for fedora-messaging users to use from their homes that isn't this/ 19:14:52 yeah, so I think this is that... the outgoing fedmsgs 19:15:09 I'm against just turning it off without notice. 19:15:26 the monitoring was just to make sure it's running and not filling up 19:15:28 yes of course, if we turn off we need to announce it 19:15:51 it broke because we moved proxies to f31 and python3 19:16:10 so before it was 'fedmsg-gateway' and now it's fedmsg-gateway-3 19:16:23 * nirik tries something dump 19:16:27 dumb even 19:17:20 i think we could announce that we're turning it off in n days and then do that, instead of figuring out how to monitor it. as long as we do have a good story for people at home tailing fedora-messaging messages 19:17:25 we do have that too, right? 19:17:30 * bowlofeggs isn't actually sure we do 19:17:42 bowlofeggs: yes we now have it 19:17:47 excellent 19:17:48 we do for that... but there is another case... 19:18:01 fedmsg-trigger I don't think is covered? 19:18:08 oh i don't know that one 19:18:09 what is that? 19:18:10 what all needs to be ported to python3 to get the current setup fixed? Is it just a script or two? Or all of fedmsg? 19:18:14 bowlofeggs: hum actually not as simple as fedmsg-tail, it needs a little bit of scripting 19:18:33 the nagios plugins are python2 19:18:50 ok that seems easy enough to fix (without actually having seen them yet) 19:18:59 I can look at porting 19:19:11 relrod, a couple of nagios-plugins in Fedora Infrastructure and bugfix fedmsg-gateway-3 to open the right socket name 19:19:19 oh i didn't know the current setup is actually broken, i thought it just needed monitoring 19:19:24 yes but that's not a great use of the time, since we want to turn off fedmsg 19:19:26 that makes it more complex 19:19:45 broken? 19:20:00 nirik: what is fedmsg-trigger ? 19:20:02 cverna: but we haven't turned it off yet. Right now it's still a production service, so we should probably monitor it. 19:20:18 the service should be working, the monitoring is broken 19:20:34 cverna: it's a script/wrapper thing to listen for matching messages and run a script on them 19:20:47 relrod: yes so the question is can we turn this service off, since we don't want people to use fedmsg anymore 19:20:50 we touted it a while back as a way for people to act on things 19:21:13 cverna: no I get that, but it's going to take time because as nirik said we don't just want to kill it without warning. 19:21:16 oh, well if the service is working, could we just say we're shutting it down in xyz days? 19:21:22 I think we should bring it up to the list and announce our intent to turn this service off and see the replies 19:21:46 oh,but the trigger thing 19:22:01 yeah, I am worried people are using that and will be mad... 19:22:02 so if we ported fedmsg-trigger to fedora-messaging, could we then announce a shut down of the gateway? 19:22:08 cverna, you will need to let people know both internal and external. 19:22:11 I think we should handle #8516 and "do we want to shut it down?" as two separate tickets 19:22:17 and I will claim 8516 and look at it 19:22:35 https://github.com/fedora-infra/fedora-messaging/issues/155 19:22:38 cverna, bowlofeggs I believe the trigger stuff is used internally for "things" 19:22:44 pagure.issue.assigned.added -- codeblock assigned ticket fedora-infrastructure#8516 to codeblock https://pagure.io/fedora-infrastructure/issue/8516 19:23:00 i guess if it's easy to fix the monitoring that could be good. but if it's not easy, and we can shut it down "soon", that could be a reasonable response too 19:23:01 I think we will have a lot of fun post colo move :P 19:23:10 relrod, I started looking at what was needed for porting and will pm you what I found 19:23:11 finding out about all these things :P 19:23:15 but i guess that also asks how easy the trigger thing is to port 19:23:23 smooge: thanks 19:23:29 looks like there is work already merged on the trigger? 19:23:36 (see above RFE github link) 19:23:47 if trigger is impportant, it should be ported anyway, because fedmsg is not reliable 19:24:49 sure. we do want to retire fedmsg. 19:24:55 * nirik wonders how much is left... 19:25:02 looking at the github ticket the trigger part is few line of codes 19:25:06 prob way more than i think is left ☺ 19:25:14 because i never heard of any of this until today 19:25:18 https://github.com/fedora-infra/fedora-messaging/issues/155#issuecomment-483252548 19:25:19 which makes me think there's more i don't know hahah 19:25:39 the known unknowns. 19:25:56 ok, so relrod is taking that monitoring thing, we already have a ticket for the trigger... move on? 19:25:58 and there can be unknown known unknowns 19:26:00 yes there is still quite a lot of work, without talking about fedmsg-meta-.. repo and fmn and badges etc .. 19:26:05 known unknowns that you forgot you knew 19:26:33 so, I see off hand, that the upload.cgi isn't moved yet. ;) 19:26:41 Do we want to gauge if we should turn the service off or not ? 19:27:03 I am happy to send a mail to the list, to see who is using that 19:27:16 I'd prefer to have a aswer on the trigger before we do, but I guess if thats going to be a long time... 19:27:52 I think we have a answer, it is a script that people have to do rather than a cli 19:27:58 cverna, the lists I believe you will need to talk to are devel, infra but I don't know what the internal ones are since I only know about their usage when it is broke 19:27:59 is that acceptable ? 19:28:34 smooge: yes hopefully the internal users are looking at the public list too 19:29:17 I guess it's a solution... seems a but more complex, but should work (I haven't tested it) 19:29:24 hahahahhahahahahahaha.. hahahahahhaha 19:30:15 I guess we run out of time :) 19:30:23 yeah... 19:30:45 we can end, or I wanted to talk with bowlofeggs about helping with some backlog... 19:31:19 ok lets do another meeting 19:31:21 nirik: we can do a 1x1 if you want for that 19:31:23 #endmeeting