[15:34:19] that's something I'm doing as the admin, right? Not something everybody does [15:34:25] Wrong number of parameters, go fix it - example @trustadd regex (admin|trusted) [15:34:25] @trustadd debt [15:34:33] Successfully added debt [15:34:33] @trustadd debt admin [15:34:43] Successfully added bblack [15:34:43] @trustadd bblack admin [15:34:55] Successfully added mark [15:34:55] @trustadd mark admin [15:34:59] thanks, bd808 [15:35:03] np [15:36:16] https://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-sre/ [15:49:07] cdanis: o/ [15:49:14] is there a swift cluster in cloud vps somewhere? [15:58:25] ottomata: you mean inside cloudvps or in use by the cloudvps servers? [15:59:08] inside [15:59:14] like in beta or somethjing [15:59:45] or, would one be easy (via puppet) to set upt [15:59:46] up*? [16:00:02] ok :-) no idea about that, but https://tools.wmflabs.org/openstack-browser/puppetclass/role::swift::storage ottomata [16:00:16] hmmmmm [16:00:26] cool thanks arturo [16:01:33] there's a swift cluster in deployment-prep somewhere. It was built a couple of years ago to replace nfs for image storage there [16:07:56] ok, bd808 do you know who maintains it? [16:08:13] i might set up temporary hadoop cluster in deployment-prep to figure out how to do access to swift in prod. [16:09:58] ottomata: figuring out who maintains anything in deployment-prep is ... not easy. Gilles might have poked at it as part of his work in the image pipeline stuff. [16:35:14] ottomata: I've occasionally been involved in swift in deployment-prep, Kren.air too iirc [16:35:25] sort of shared/collaborative ownership let's say [17:41:11] know what's up with the prometheus-node-exporter on graphite2001? [17:41:22] and does this really mean all other monitoring checks should be turned off? [17:42:42] oh, just found a decom ticket for the whole server.. hmm ok then [17:43:37] replaced by graphite2002 and used for tests. got it! [17:45:07] ok cool' [17:45:09] is graphite2002 in production though? [17:45:23] it also has notifications disabled for everything [17:45:29] godog: so if i set up a hadoop cluster in deployment-prep, you could help me figure out how to (user/creds, etc.) access swift? [18:14:14] graphite2002 was used for prometheus migration and will be used for further d-i tests [18:16:01] moritzm: ah! alright, thx [19:20:15] curious if others would find T223319 useful (and what other good targets I'm not thinking of) [19:20:16] T223319: URL shortener subdomains for useful Wikimedia infrastructure - https://phabricator.wikimedia.org/T223319 [19:26:37] if we want to namespace w.wiki, it would be better done in the path-space rather than the domainname space [19:26:47] w.wiki/b/$FOO for bugs, or whatever [19:27:14] that's my $0.02 anyways. domainnames are always more of PITA than path components [19:27:22] mm, reasonable :) [19:27:31] (and subdomains of subdomains and such, more so the deeper you go) [19:28:01] but if you really want my full $0.05 of input: I also hate .wiki with a passion. [19:28:05] heh heh [19:28:17] why's that? [19:29:09] So many reasons! (a) I dislike the gTLD money-grab in general, so I tend to prefer we don't prop up that machine by acquiring pointless gtld names (but I'm sure legal will anyways for various brand/tm things, just hopefully they're at least not canonical ones we really use) [19:30:02] (b) I specifically dislike what happened with ".wiki" as well, which goes back to decisions made long ago under past leadership, etc.... Basically someone else bought/created .wiki, and then offered to delegate to us various language subdomains and such for our use.... [19:30:15] nod [19:30:33] so we don't own ".wiki", but we do own in theory "en.wiki" and the rest. "w.wiki" got put into use and I couldn't stop it, but I argued pretty hard and probably was what shut down the rest of them. [19:31:27] because they're also going to host a bajillion other unrelated things in .wiki that aren't us, so it's brand-confusion at best, and at worst it's an outright malicious ploy... to get the wikipedia branding confusion to bleed to .wiki and to whomever else they sell domainnames to by extension. [19:31:45] (if the world finds "en.wiki" to be canonical for us and starts accepting that, how do they know foobar.wiki isn't us?) [19:31:54] yeah, that's really not great [19:32:05] I honestly wish even w.wiki would go away, but we seem to have lost that battle a long time ago [19:33:28] (the key winning argument against all the other "en.wiki" and such was technical rather than the above though: since we don't own .wiki we can't get a *.wiki HTTPS wildcard cert, and it's also ridiculous for us to purchase/managed/deploy a few hundred separate cert SANs for all the language subdomains there... but that was back before LE made it easier) [19:34:28] anyways, you can still see the legacy of all of that stuff in whois and rootservers, e.g. "en.wiki" is still delegated to us, but we're not serving it [19:34:56] someone made lots of plans around this whole scheme before talking to us about it and it getting mostly-shot-down heh [19:35:19] heh [19:35:36] all makes sense. I had some guesses around this but it's nice to know the actual context [19:41:30] if we had actually bought the whole of .wiki it would be different. I'd still dislike us wasting donor money on the gtld money-grab scheme, but someone could make the argument it's worth it and non-confusing at that point. [19:41:50] (and we could get a wildcard for the whole thing, maybe) [19:42:15] (although that might still be tricky, I'm not sure how wildcards and gTLDs intersect, or whether there's some special rules that prevent single-org use of a gTLD, etc) [19:45:18] my naive thought was just that it's a lot shorter to write "# remove this when http://w.wiki/b/T12345 is fixed" in a comment or similar :) [19:47:21] ottomata, I don't think many people have really touched deployment-ms-* instances beyond go.dog and myself [19:48:10] I don't know much about how swift users/credentials work though I could probably figure it out [19:49:46] in prod swift, accounts are just statically declared, and the passwords are puppet secrets [19:49:54] likely similar there [19:50:02] yeah [20:05:56] but hm Krenair cdanis ok i'm looking for e.g. https://docs.openstack.org/sahara/latest/user/hadoop-swift.html [20:06:05] what to put for fs.swift.service.${provider} [20:06:15] i believe $provider is whatever i name it [20:06:28] e.g. I guess I should use the ms-fe host? [20:06:31] not the be one? [20:06:32] s [20:07:18] oh hm i see in /etc/swift on ms-fe03 [20:07:22] e.g. account_AUTH_mw.env [20:07:28] which i guess has some examples [20:07:40] yeah you will want to talk to swift via the ms-fe hosts [20:07:55] so -- I'm *not* at all sure of the significance of the provider names in this plugin [20:08:07] all the examples assume you're using rackspace's or whichever other service provider's swift install [20:08:08] i think prodivider names are just to support multple clusters [20:08:14] rather than running your own [20:08:29] all the .${provider}.* configs [20:08:37] would then be used e.g. for swift urls like [20:08:44] swift://./file/to/copy [20:08:45] so [20:08:57] swift://.$provider/file/to/copy [20:09:07] but for the actual configs [20:09:08] I think the version of swift we have is from openstack newton [20:09:22] what is e.g. .tenant [20:10:36] a tenant in openstack is what we'd refer to as a project in labs... but obviously it is unconnected to our labs setup. I'm not sure how it applies to our swift containers [20:14:07] yeah, I don't know