[10:07:00] <topranks>	 Reminder that today at 14:00UTC we will upgrade eqiad row A switches - https://phabricator.wikimedia.org/T329073
[10:07:20] <marostegui>	 topranks: wasn't that the 7th??
[10:08:04] <topranks>	 marostegui: haha, correct :P
[10:08:20] <marostegui>	 topranks: I get this was you testing us, right
[10:08:45] <topranks>	 yes of course, passed with flying colours :)
[10:08:53] <marostegui>	 \o/
[10:09:36] <topranks>	 To be clear - upgrade is schedlued for TOMORROW March 7th
[10:09:38] <topranks>	 Apologies I got my days mixed up.
[10:11:29] <elukey>	 topranks: monday drill and only marostegui answered correctly, so I'd argue that it is not all flying colours :D (me included)
[10:13:03] <claime>	 Maybe 4 minutes to answer was a bit short :P
[10:15:56] <elukey>	 claime: we don't handle databases, our perception of time is different
[10:16:20] <elukey>	 marostegui usually resolves outages in 4 minutes
[10:17:23] <claime>	 :D
[10:36:40] <akosiaris>	 that's the theory of general database relativity for ya 
[10:47:27] <elukey>	 the higher the importance of a db the slower the time flows nearby :D
[10:47:55] <claime>	 Except when you actually want to act on it, then it flows faster.
[10:48:08] <claime>	 Quantum exception to the general database relativity
[10:54:00] <_joe_>	 you all should really not make physics jokes
[10:54:50] <claime>	 You're not my dad
[10:54:59] <claime>	 :p
[10:55:19] <_joe_>	 i'm trying so hard not to correct your jokes :P
[10:55:42] <claime>	 lol
[10:55:50] <claime>	 "AKCHUALLY"\
[11:04:57] <elukey>	 _joe_ we were having fun before you ruined it :D
[14:09:48] <_joe_>	 I had forgotten about vulture_whitelist.py
[14:10:00] <_joe_>	 I was thankful I did
[15:19:27] <dcaro>	 urandom: ping! Can I merge your puppet change on the puppetmaster?
[15:19:36] <dcaro>	 "swift: add ms-fe201[3-4] as new Swift proxy nodes (653d0948d4)"
[15:19:47] <urandom>	 dcaro: oh, yes, duh!
[15:19:50] <urandom>	 sorry
[15:19:57] <dcaro>	 👍 np
[15:20:13] <vgutierrez>	 hmmm grafana.wm.o is redirecting me to grafana-next-rw, is that expected?
[15:21:55] <volans>	 wut? indeed, vgutierrez you should ask in o11y, but I don't think is expected
[15:23:22] <elukey>	 volans: this may be related https://sal.toolforge.org/log/xrBtt4YB0IdT-khDx0bZ
[15:23:39] <elukey>	 err vgutierrez --^
[15:23:41] <elukey>	 and herron 
[15:31:55] <herron>	 thanks yes that was not expected, should be improved with the temporary workaround that's in place now
[15:32:00] <herron>	 now working on persisting that
[15:32:35] <marostegui>	 why isn't sirenbot updating the topic on this channel?
[15:32:50] <claime>	 Because it doesn´t autoop
[15:32:54] <marostegui>	 :_(
[15:34:01] <claime>	 Happy sirenbot is happy
[15:34:09] <herron>	 wb sirenbot
[15:34:09] <marostegui>	 you are welcome sirenbot 
[15:35:25] <hnowlan>	 I have a potentially stupid question - is it out of convention or necessity that usernames have their first letter capitalised in icinga configs? It's a bit messy with the SSO setup and I was wondering if something would break if I changed my name to be lower case (I see an alternative option is just adding a second lower cased version) 
[15:36:33] <herron>	 convention that predates the idp system afaik, should be fine with lower
[15:36:36] <claime>	 lol
[15:36:51] <claime>	 poor sirenbot gets floodkilled when you ask it its acls...
[15:36:56] <claime>	 My fault
[15:38:20] <moritzm>	 hnowlan: convention, see https://phabricator.wikimedia.org/T256656#6266825 for some background
[15:41:08] <claime>	 What's weird is that sirenbot is in ircservserv config for the channel as plus_o
[15:41:22] <claime>	 So I must be missing something regarding how our channel rights are setup
[17:15:11] <inflatador>	 bblack can you link that ticket when you get a chance?
[17:16:05] <inflatador>	 as in, the wikidata http blocking task
[17:17:17] <bblack>	 https://phabricator.wikimedia.org/T330906
[17:19:27] <inflatador>	 got it, thanks!
[17:23:01] <bblack>	 which I just noticed got closed, so I re-opened it :P
[17:26:12] <bblack>	 makes me wonder if maybe we should start intentionally-degraded port 80 service over time, to annoy the world into fixing these things on their own
[17:26:31] <bblack>	 Start at an intentional 5% failure rate and ramp it up over a period of years or whatever
[17:27:40] <rzl>	 some kind of an... objective... for service level...
[17:27:44] <rzl>	 it's crazy but it might just work
[17:27:45] <vgutierrez>	 /nick chaosmonkey
[17:27:47] <vgutierrez>	 let me handle that
[17:27:53] <vgutierrez>	 O:)
[17:28:32] <bblack>	 :P
[17:28:41] <rzl>	 actually that's a great point, IIRC we don't distinguish between 80 and 443 in our existing traffic SLOs and maybe that's a good place to start
[17:39:02] <mutante>	 btw, this is around https://phabricator.wikimedia.org/T226453#5294638
[17:39:13] <mutante>	 "concept URI"
[17:41:02] <mutante>	 https://www.w3.org/DesignIssues/Security-NotTheS.html  "A proposal then is to do HTTPS everywhere in the sense of the protocol but not the URI prefix. "  well, that's gonna be confusing
[17:42:32] <mutante>	 so then it would have to wait for phasing out https:// entirely, heh  "The HTTP protocol can and by default is upgraded to use TLS without having to use a different URI prefix. The https: prefix could even in fact be phased out,"
[17:52:55] <mutante>	 Reedy: https://deletionpedia.org/en/Main_Page has deleted their main_page (years ago?:), where's deletiondeletionpedia.org
[17:56:02] <bblack>	 yeah I get that, but it's silly
[17:56:13] <bblack>	 if you keep sticking http:// in places, it's going to cause problems, that's the bottom line
[17:57:08] <mutante>	 yea, and introducing an entirely new prefix sounds like something that isn't going to happen anytime soon
[17:57:46] <mutante>	 except where we already use just "://" or so internally in some places
[17:57:59] <bblack>	 that's valid as well (protocol-relative URIs)
[17:58:25] <mutante>	 maybe it should be that as the concept URL then.. but dunno
[17:58:41] <mutante>	 URI even
[17:58:53] <bblack>	 I really don't know what their concept URI really means.  I assume it means more or less "we're using this URI also as effective a key in a KV-system"
[17:59:50] <bblack>	 in other words, the http:// URIs are now "keys" that the wikidata ecosystem relies on to identify data items.
[18:00:39] <bblack>	 honestly, I don't really want to know all the internal details that badly.  I just the result to be that wikidata emits/uses https:// URIs for access purposes.
[18:00:44] <bblack>	 s/just/just want/
[18:02:29] <bblack>	 which is something we thought/assumed was already the case.  We fixed this "for all the wikis" years ago by changing all their $wgCanonicalServer to be https://whatever
[18:02:36] <bblack>	 including wikidata with the wmf-config line:
[18:02:38] <bblack>	 'wikidatawiki' => 'https://www.wikidata.org',
[18:02:58] <bblack>	 we just didn't realize there was some other problem in wikidata that doesn't honor that
[18:03:02] <mutante>	 yea, it was suprising to see a comment like "I guess the standard is now towards https" in 2019 after all that years earlier
[18:03:24] <mutante>	 also found ancient ticket that was still in RT.. that was about "wikidata redirects https to http" heh
[18:22:32] <mutante>	 did you know that Jimmy sold off his first Wikipedia edit as an NFT for 750K back in 2021
[18:43:04] <ebernhardson>	 i heard he was doing that...but wow i didn't realize it went for 750k
[20:03:34] <ryankemper>	 ^ frankly the way the nft / crypto market was exploding in 2021, I'd be more surprised to hear about NFTs that sold for less than 750K :P
[20:04:00] * ryankemper remembers getting text messages from friends he hadn't talked to in years asking about which monkey NFT they should buy
[20:32:20] <jhathaway>	 is there a way to exclude hosts where puppet is disabled in cumin?
[20:38:16] <rzl>	 jhathaway: I don't think cumin itself knows, but you could do it with `sudo cumin A:whatever "puppet-enabled && echo 'puppet is enabled on this host'"`
[20:38:54] <jhathaway>	 rzl: nod, thanks, I thought maybe it would be exposed somehow as a virtual puppet fact or something
[20:39:11] <rzl>	 (or fancy it up a bit if you wanted the exit codes to come out differently)
[20:39:31] <rzl>	 I *think* there's only the lockfile on the host itself, not positive
[20:40:35] <jhathaway>	 yeah good point, it would have to interogate the host directly
[20:49:22] <volans>	 what reuven said, even if it was exposed somehow to puppetdb in a queriable way it would be only every 30m, while puppet could be enabled/disabled at will
[20:51:51] <volans>	 couple of additional possible things jhathaway, there are some utility functions in /usr/local/share/bash/puppet-common.sh and if needed you can source the file and run one of them.
[20:52:08] <volans>	 the other, slightly unrelated, is that you can run puppet only where it failed, see https://wikitech.wikimedia.org/wiki/Cumin#Run_Puppet_only_if_last_run_failed
[20:52:49] <jhathaway>	 volans: thanks, I think the puppet-enabled method works pretty well, given its exit code
[20:53:10] <volans>	 yes that works, depending on what you need
[20:53:14] <volans>	 you can also do: 'puppet-enabled && echo "yes" || echo "no"'
[20:53:59] <volans>	 or, if you're running a read-only operation, use cumin -x/--ignore-exit-codes
[20:54:47] <jhathaway>	 I went with 'if puppet-enabled >/dev/null; do <CMD>; fi'
[20:55:15] <jhathaway>	 also as an aside the json output is really nice
[20:55:25] <jhathaway>	 for cumin that is
[20:56:52] <volans>	 I guess s/do/then/ :-P
[21:02:05] <jhathaway>	 ah yup good catch!
[21:02:36] <volans>	 puppet-enabled doesn't print anything if enabled IIRC
[21:05:02] <jhathaway>	 right again, so no need for the /dev/null