[00:15:55] !log image-suggestion-api deleting project after discussion with bpirkle [00:15:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Image-suggestion-api/SAL [00:16:51] Southparkfan: the host you made is it's 'ircd03' not 'irc03' :D [08:00:57] hello everybody, I'm having problems to log into toolforge using putty, is this the right place to find a solution? thanks a lot [08:02:43] jminguillona: yep, did you follow https://wikitech.wikimedia.org/wiki/Help:Toolforge/Quickstart#Set_up_an_SSH_client_and_a_key ? What error are you seeing? [08:02:54] hello :) [08:04:37] hello, yes I created a key using puttygen, followed all instructions, open the ssh session, asks for my private key, but it suddenly closes the session [08:05:26] if I provide a wrong password it complains, so it's something related to establishing the session, but no idea [08:07:46] did you add your key to https://toolsadmin.wikimedia.org/profile/settings/ssh-keys/ ? [08:08:24] yes [08:08:31] did you request membership? https://toolsadmin.wikimedia.org/tools/membership/apply [08:08:59] you have to have a tool in mind already, if you have some code that would help a lot with the approval [08:09:15] oops, no, thanks [08:09:54] np, make sure to follow the first steps https://wikitech.wikimedia.org/wiki/Help:Toolforge/Quickstart#Get_access [08:10:01] (if you haven't yet) [08:10:02] we have a script to scrap some wikipedia web pages regularly, we were told that tooolforge was the best place to do so [08:11:55] that sounds good yes, make sure to explain a bit there in the request what you use those scrapes for and how it helps the movement (and if you have the script code somewhere a link to it, everything running on toolforge must have an FLOSS license and be published, you can use gitlab.wikimedia.org for that if you want, once the tool is approved you can automatically create a repo there) [08:12:27] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Rules [08:13:03] note that publishing your code anywhere else is ok also as long as it's public (ex. github, gerrit, ...) [08:14:48] ok I just made the request, with some info about the project [08:14:51] thanks a lot! [08:16:52] jminguillona: request has been accepted [08:18:24] jminguillona: make sure to subscribe to https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.org/ to get notices of platform changes and maintenance windows and such [08:18:56] give it a minute also to ssh, as it has to create your tool home dir, etc. xd [09:13:45] andrewbogott: yeah, it was too late for me I guess, sorry :) [09:15:31] thanks a lot, I already logged in!!! [09:28:16] !log deployment-prep create deployment-jobrunner05 with Bullseye image, T370487 [09:28:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [09:28:20] T370487: Remove or replace deployment-jobrunner04.deployment-prep.eqiad1.wikimedia.cloud (Buster deprecation) - https://phabricator.wikimedia.org/T370487 [09:33:03] !log wikidata-dev wikidata-icinga: shut down instance, will try to bring up a replacement on newer base OS [09:33:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [09:35:27] !log wikidata-dev wikidata-icinga-2024: instance created, will try to set up using https://github.com/tarrow/wmcs-icinga/tree/master/infrastructure [09:35:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [09:44:58] !log wikidata-dev wikidata-icinga-2024: set up instance (see https://github.com/tarrow/wmcs-icinga/pull/1), wikidata-icinga hopefully no longer needed [09:44:59] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [11:03:27] !log deployment-prep switched over cpjobqueue (running on deployment-changeprop-1) to deployment-jobrunner05 T370487 [11:03:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [11:03:31] T370487: Remove or replace deployment-jobrunner04.deployment-prep.eqiad1.wikimedia.cloud (Buster deprecation) - https://phabricator.wikimedia.org/T370487 [14:31:15] Southparkfan: do you have gerrit patches I can review? Or is there anything else I can do to help w/your rampage? [14:33:23] andrewbogott: https://phabricator.wikimedia.org/T370487 has two patches [14:34:04] and https://phabricator.wikimedia.org/T369919 has one patch [14:34:33] after merging, I can delete the old jobrunner (controlled, to not break the beta sync-world job again) and release one floating IP [14:34:43] and remove one RRset from the wmflabs.org zone [14:35:34] Southparkfan: what about that '-1 do not merge yet' comment? [14:35:42] which one? [14:35:49] https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1055394 [14:36:03] yeah, because it was a WIP [14:36:14] but no longer, right? So you can unset? [14:36:16] yep [14:36:21] cpjobqueue is now using jobrunner05 [14:36:26] (gerrit sort of doesn't want me to merge while it's set WIP) [14:37:45] ok, +2'd all of those [14:56:40] so, chown -r [14:56:57] hm [15:01:48] alright, I have to go in a few minutes for a party, but two new appserver nodes are being set up [15:02:17] nice! [15:05:50] southparkfan@deployment-mediawiki13.deployment-prep.eqiad1.wikimedia.cloud: Permission denied (publickey). [15:05:53] sad [15:09:18] I did the thing with puppet certs on the local puppetserver and am re-running puppet, maybe it'll sort out logins [15:09:32] (It has a ton of work to do, though, because appserver) [15:10:28] hmmmm or maybe ssh requires some special group membership for those hosts? [15:10:44] My personal key doesn't work either [15:12:19] I don't have time to look at it right now [15:13:00] but we're down two Buster machines now, and after fixing the login issue moving the two appservers should not be impossible either [15:13:57] hm, personal key works on the old app servers (11,12) but not on the new ones (13,14) so something interesting is happening :( [15:14:16] I'll leave a note here about what I find [15:35:24] Is sqlite actually the best option for my tool? Inserts/updates are rare and very unlikely to be concurrent, reads are not highly concurrent and I'd cap it at 3 queries/s at maximum. Currently the .db file is less than 1MB and I don't expect it to grow much larger. I read on wikitech that sqlite would be using NFS which should have performance problems, but at first I [15:35:24] used the to [15:35:25] olsdb but it was slower [15:37:19] Southparkfan: fixed now, some kind of foul-up with cloudinit [15:38:07] thanks! [15:39:58] deadbf, sqlite would probably work for you in the short term but the less you rely on NFS the better. If things are working with toolsdb best to stick with that. [15:43:55] Thanks for the reply, andrewbogott. I moved off from toolsdb because it was quite slow for reads. It takes about 0.5s for a single query while it appears to be instant for sqlite. I'm suspicious that most of the latency came from the network connection to the database, but I haven't done extensive testing. [15:45:19] I would not expect it to be nearly that slow but haven't tested recently [15:56:25] andrewbogott: could you +2 https://gerrit.wikimedia.org/r/c/operations/puppet/+/1055464 ? :) [15:57:09] yes but you should also go to your party [15:57:52] indeed, that's why I'm working in the train [15:58:21] ok, fair excuse [16:06:39] yep, puppet repo doesn't want to sync yet again [16:06:57] despite chown -R using gitpuppet and oneshot-ing puppet-git-sync-upstream [16:07:52] complaining about permission errors yet again :) I guess that python sync script should do a better job of su'ing as gitpuppet [16:10:05] yeah, I'm doing some tests there now [16:17:21] it's in sync again for the moment [16:56:39] !log deployment-prep switching trafficserver backends from mediawiki11 and 12 to 13 and 14 - T361387 [16:56:43] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [16:56:44] T361387: Replace or delete deployment-mediawiki[11-12].deployement-prep.eqiad1.wikimedia.cloud - https://phabricator.wikimedia.org/T361387 [16:56:59] so far so good [17:01:37] andrewbogott: ^ going to stop for today, the buster appservers are still used in a few places, but I'll take care of that later [17:01:58] sounds good, thanks again for working on this [17:02:10] as far as I can see the references to the former appservers are solely in horizon hiera, shouldn't be too hard once I find more time [17:02:35] my pleasure [17:03:49] (but no guarantees for the future!) [17:07:57] you can grep horizon hiera by checking out https://gerrit.wikimedia.org/r/admin/repos/cloud/instance-puppet,general [17:27:41] !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed 4757a1f91e (l100n updates: de, nb, uk) [17:27:43] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL [17:28:03] wow, that’s like 10× the amount of updates!! [17:32:25] (in case anyone was wondering if those messages are logged automatically or written by hand :P) [19:00:53] What would be an appropriate ip range to identify request that come from within the cloud infra and received by beta-cluster? This is related to test deploying https://www.mediawiki.org/wiki/Extension:NetworkSession [19:01:45] It will end up creating an account, but the account will only have the 'read' permission so it shouldn't really matter [19:05:23] the main goal of the ip range is to be able to clearly see it working in one place and rejected in another [19:05:50] ebernhardson: https://phabricator.wikimedia.org/P66844 [19:05:58] ebernhardson: https://gerrit.wikimedia.org/g/operations/puppet/+/51110996bfafcaff929c78bd5b14bf5d4938b2bf/modules/network/data/data.yaml [19:06:07] in that second link, see lines with "cloud-hosts" [19:06:17] mutante: excellent, thanks! [19:08:39] also line 29 with that 172.16.0.0/12 [21:18:03] !log tools.ircservserv Created https://gitlab.wikimedia.org/toolforge-repos/ircservserv-config via Striker [21:18:05] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.ircservserv/SAL [21:18:11] !log tools.ircservserv Created https://gitlab.wikimedia.org/toolforge-repos/ircservserv via Striker [21:18:12] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.ircservserv/SAL [21:20:49] andrewbogott: unfortunately it looks like taavi's 8438917b952480ec20c2cf6667a1d6e9e07e1973 commit is breaking ci [21:20:54] https://integration.wikimedia.org/ci/job/operations-puppet-tests-buster/5820/console [21:29:54] andrewbogott: is reverting safe? [21:30:30] jhathaway: yes, go ahead and revert [21:30:56] ok, will do thanks [21:31:03] how is it affecting CI though? Doesn't it only apply on cloudvirts? [21:31:49] huh [21:31:56] If you look at https://integration.wikimedia.org/ci/job/operations-puppet-tests-buster/5820/console [21:32:02] Yeah, I see. [21:32:04] you see that some of the rspec tests are now failing [21:32:07] I don't follow yet but it's fine to revert [21:32:17] ok [21:32:25] reverting.. [21:34:18] reverted, thanks [21:35:12] I've been bitten by the rpsec tests one to many times