[11:37:52] !log admin [codfw1dev] replacing cloudnet2003-dev with cloudnet2004-dev (T281381) [11:37:55] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [11:37:55] T281381: Cloud: replace cloudnet2003-dev with cloudnet2004-dev - https://phabricator.wikimedia.org/T281381 [11:52:04] arturo: I have another one: https://gerrit.wikimedia.org/r/c/operations/puppet/+/689785 btw also to check the interval you can run "sudo systemd-analyze calendar 'INTERVAL" [11:52:43] this seems to be only toolforge (grid) [11:53:26] nice! [11:54:14] Amir1: thanks, merged [11:54:51] Thanks. Let me know if it caused any issue [11:54:57] there are so many more to clean up :D [11:55:37] * arturo sends best wishes to Amir1 [12:37:10] Amir1: I would like to not be subscribed to the listadmis@l.w.o mailing list. Too many email already [12:38:51] arturo: you can easily unsub (see https://lists.wikimedia.org/hyperkitty/list/listadmins@lists.wikimedia.org/thread/6TI3WJTZCYGD4MPJR6XKQ25UOE3XDFKG/ ) [12:39:02] do you have an account in the new thing? [12:40:57] Amir1: yeah, I mean. I already unsubscribed, but wanted to checkin with you [12:41:07] The work you have been doing with mailman is awesome, really appreciated [12:41:26] Thanks Kunal is doing most of it ^^ [12:41:30] this is just me trying to figure out how to stop having 1K unread emails every day [12:41:33] yeah, only -announce is important [12:41:45] wow :( [12:42:15] obviously I don't read them, but perhaps the strategy is not recv them in the first place hehe [12:43:42] less pressure on our already terrible exim4 servers :D [12:44:08] :-P [14:09:15] If ever learned to lint my patches locally before submitting to gerrit that would probably reduce your daily count by 50% [14:14:58] same problem here. $something changed in the ruby gem mess that prevents me from running the linters locally [14:22:59] !log admin [codfw1dev] cleanup old unused agents (bgp, ovs) [14:23:01] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [14:44:03] FWIW for me utils/run_ci_locally.sh *tends* to DTRT, and uses docker so practically nothing installed locally [15:05:49] godog: good hint! [15:20:20] Hey cloud team! Is https://download.wmcloud.org/ still in use? and if so, Im looking for a place to put a sqlite database file for use by a proof of concept API. Would putting it there be a good use case? [15:50:26] nikkinikk: I don't know about that service, but a simple tool in toolforge to offer a file to download seems a good use case [15:50:40] nikkinikk: similar to this: https://network-tests.toolforge.org/ [15:51:12] nikkinikk: I'm not sure what download is but you can serve static files from a toolforge tool easily https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Static_file_server [15:51:16] download.wmcloud.org still exists and is used for a couple of things. It's not at all self-serve; if you want a file hosted there you can make me a ticket with a link to the file [15:51:20] arturo: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Hosting_large_files [15:51:20] arturo beat me heh [15:51:28] nikkinikk: an sqlite db that you will be using as a db? Or seed data for something? [15:51:52] the most answered help request ever :-P [15:51:55] does it show we all finished the same meeting at the same time? [15:52:04] (btw arturo, this is a straightforward use case for swift) [15:52:06] that was a strong output of responses hahaha thanks all [15:52:16] andrewbogott: yeah [15:52:19] download is basically a hack we made to take load off the NFS server for really large static downloads [15:52:19] bd808: using the file as a DB [15:52:44] sqlite is like the worst db to use in Toolforge/Cloud VPS [15:52:46] but the api is hosted on cloud vps [15:53:03] LOL whys that? [15:53:10] why not host sqlite in the cloudvps instance? [15:53:12] sqlite causes a lot of file churn [15:53:29] in toolforge it is rally bad because that's NFS backed [15:53:33] *really [15:53:56] on a Cloud VPS instance, I guess it's fine. But why not a "real" database? [15:54:23] but never on download, that's a file delivery service not a live file hosting container [15:55:31] joakino: this was originally a POC/MVP/WhateverMinimalAmountOfWorkIsPossible project so we went for the easiest/quickest approach since sqlite was supposed to be an in-between approach until we got access to our own dedicated Cassandra db [15:55:43] I like SQLite πŸ™ˆ [15:56:12] bd808: thats good to konw about sqlite we were having a lot of problems on toolforge hence why we moved it over to cloud vps! [15:57:04] the easy db solution for a Toolforge tool is ToolsDB -- https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#User_databases [15:57:30] the coming real soonβ„’ solution will be Trove (OpenStack db as a service) [16:03:03] I actually never saw that part of the docs, thanks!! This is kind of a weird in-between phase, where we have a few people working on getting a Cassandra DB instance up and running. Just needed something to work until then. Given that we're on cloud VPS, would you still not suggest hosting a db file on somewhere then? And just suggest actually hosting it on its own? [16:04:23] nikkinikk: you can certainly host it in your own Cloud VPS project. It's just not a good use case to host it outside your project. sqlite works by local filesystem access, not across a network. [16:04:57] * bstorm comes from the shadows ready to defend sqlite [16:06:03] ah ok I should explain a bit more! We have it hosted in our own project right now. But want it to be included in our Docker containers at container creation time in CI (to publish to k8s). [16:06:07] if you need a b-tree index for a toy, sure. if you need perf and scale and the ability to evolve a schema, ok if you want to do that work go for it [16:07:25] nikkinikk: so what you really want is to collect data into an sqlite db and then pull that db into a pipelinelib build phase? [16:08:07] bd808: yes - I really should have included that in the original question 😬 [16:08:41] Well, not generate the actual data at build time. Just use an existing db file. [16:08:44] nikkinikk: I guess the quickest hack for that would be hosting the db file in your Cloud VPS project and setting up a web proxy to serve it over https. https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_VPS_servers_from_the_internet [16:08:54] I just won't use it for lots of heavy writes, especially for concurrent activity, that's what transactions are for. If you have a single, linear write activity and no real security concerns, it's amazingly good at what it does. [16:09:54] bstorm: Yes its all reads right now, no writes at all :) [16:10:47] Very public data I'm getting from the backscroll? [16:11:38] bd808: ok i dont know why i didnt realize that i could just download it from the actual cloud vps instance itself.... [16:12:00] nikkinikk: E_TOO_MANY_OPTIONS :) [16:12:01] If you keep it on a cinder volume, it can outlive your VMs and yeah, using your own very simple web server to serve it seems like a way. download.wmcloud.org isn't the worst place for it...it's just definitely not flexible :) [16:12:40] Just as long as you are ok downloading it locally during your builds or whatever, which is what I'm getting...you aren't trying to host it directly from the web, no? [16:13:09] If you don't expect to ever update it, then download.wmc.o is fair [16:13:33] Otherwise, it's really just a blob store we use as a last resort kind of deal [16:13:58] Thus why everyone looked for an alternative for you :) [16:15:00] bstorm: yes very public data, and yes would like to download it at build time. But it will be updated every 30 days-ish. (although this is still just an in-between solution that hopefully shouldnt even exist in 30 days, but then again it might...lol.) Since it would be updated, maybe download.wmcloud isnt the best then? and will just pull from cloud VPS instance in that case [16:16:26] +1 100% agree with bd808 on that option [16:16:35] πŸ™ thanks all so much for your help/recommendations !! [19:03:51] !log tools deleted phamhi from admin configmap in maintain-kubeusers T282725 [19:03:55] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [19:03:56] T282725: maintain-kubeusers: Remove admin access from users removed from tools.admin - https://phabricator.wikimedia.org/T282725 [19:04:18] !log tools deleted the maintain-kubeusers pod to get it up and running fast T282725 [19:04:21] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [19:05:26] !log tools remove phamhi-binding phamhi-view-binding cluster role bindings T282725 [19:05:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [19:33:00] !log paws added taavi to paws.admin [19:33:02] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL [19:43:49] !log tools.sge-jobs Updated target url of update-cache cron job to point at sge-jobs.toolforge.org hostname. [19:43:51] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.sge-jobs/SAL [19:45:33] !log tools cleared error state from some queues [19:45:35] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL