[00:20:10] !log tools.stewardbots stewardbots/StewardBot/manage.sh restart # Ping timeout not noticed by the bot [00:20:12] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [10:06:27] !log terraform created new project T316473 [10:06:30] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Terraform/SAL [10:06:30] T316473: Request creation of terraform VPS project - https://phabricator.wikimedia.org/T316473 [11:42:22] !log quarry 826948: update XlsxWriter plugin | https://gerrit.wikimedia.org/r/c/analytics/quarry/web/+/826948 [11:42:24] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Quarry/SAL [13:01:48] Hi folks [13:01:49] I don't remember if a Toolforge project can create its own MariaDB database with some tables etc. or if a cloud VPS is needed for that [13:02:25] I was not able to find this info from [[wikitech:Help:Toolforge/Database]] [13:02:37] [[Help:Toolforge/Database#User_databases]]? [13:02:59] Thanks! [13:39:03] Does the 'webservice' command support custom domains? [13:39:04] For example to associate an owned foo.org to a Toolforge tool. [13:39:06] This is obvious for cloud VPS, but maybe not supported in tools. Thanks [13:39:31] no, those are not really supported in either environment [13:56:49] (surprised pika meme) [13:56:49] OK thanks [14:07:39] I've put a small note in [[Help:Toolforge/Web]] [14:16:28] Premise: in Toolforge, big files (>1G) are not allowed. But what about total project space? [14:16:28] I presume requiring >= 10G is absolutely not suitable for Toolforge, since AFAIK the NFS share is less than 20G in my current bastion if I'm not wrong. [14:23:19] So if the requirement is 30G of sparse data, I think you recommend to send this request to Cloud VPS. Right? [14:25:20] it's really hard to say anything without knowing anything about the tool or the data it needs [14:26:02] the 3000+ tools are definitely using more than 20G total storage [14:29:04] The tool will be a sort of "image uploader". Kind of "pre-Commons" for Wiki Loves Monuments in a specific country. [14:29:24] So, sparse files, with expected max. req of 30G [14:32:50] Kind as simple "dear museum, drop here in CC0" and then "let's delete unuseful stuff and upload on Commons". Expecteds: 1000 museums, 20 photos, 1.5M/photo, so ~30G max expected. [14:55:26] Maybe it's better to open a Task to ask that [14:58:22] @bozzy: A Cloud VPS project would likely be a better fit than Toolforge if only because a Cloud VPS project has more flexibility in adding storage and keeping that isolated from other projects. Toolforge only has NFS for storage. [14:59:00] But I also wonder about the general need for a "pre-commons" [15:00:33] Why not upload to commons and then mark the "unuseful" things for deletion? Commons will have more storage and better performance than almost any Cloud VPS project. [15:02:35] Question. Things deleted from Commons actually stay on the storage forever. Right? [15:03:20] Yes [15:03:31] Except in special circumstances, yes. (RevDel happens, but not commonly) [15:03:33] Unless they are removed by T&S [15:07:05] OK thanks. [15:07:06] Another point: the project is trying to do things right and legally, so we have 1000 museums that cannot actually upload free contents directly to Commons, and who receives their material need to manually verify their manual authorization. Then Commons. [15:07:45] Yes, there is a person who verifies a scanned piece of paper in which a museum manager authorizes the release in free license, before uploading on Commons. [15:09:10] This way the Commons community does not receive an avalanche of problematic data. We felt it was more respectful to them. [15:10:00] you can't store material with unclear copyright status on WMCS either.. [15:11:40] https://commons.wikimedia.org/wiki/Commons:Volunteer_Response_Team is exactly for things like reviewing and validating image releases as well. I'm not saying I know enough to say that there is no need for a staging process, but this all sounds like things that the community knows how to deal with. [15:12:45] Thanks. I will take this feedback back to those who are following the project. I am just doing volunteer consulting as well. [15:18:17] By the way, the VTRS will be used. But VTRS and Commons will not be used as data entry platform and as file storage. [15:26:41] Thanks again. I've quoted you here: [15:26:42] https://wiki.wikimedia.it/wiki/Empowering_Italian_GLAMs/Tool [15:26:43] [15:26:45] Current project description (Italian): [15:26:46] https://wiki.wikimedia.it/wiki/Empowering_Italian_GLAMs [15:38:48] (It's written in Italian but, please note that the reported budget is spread over 2 years, and that there are 10 people involved, and the developer is only one of them. So please be nice with the developer and this project, who certainly doesn't get rich from this.) [16:23:33] I think we will proceed with a Cloud VPS. [16:23:34] [16:23:36] I have not mentioned that there is a lawyer involved in this process, and they are activist in Creative Commons Italy. This should assure correct authorization and Open Access Policy workflows and the respect of [[Wikitech:Cloud Services Terms of use]]. [18:48:54] !log paws jupyterlab version bump 0b2532f0590fc5c1ae5b5f5a7148bdf9f4b1f92c T308042 [18:48:57] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL [18:48:58] T308042: update jupyterlab - https://phabricator.wikimedia.org/T308042 [20:33:00] !log tools.heritage Deploy da97380, d5780dc, 49ddbcb, 327c03b, 14c4ca9, 74bff71, 7d866b7, 11fb1b0 (T307269), 406909f, 857152e (T225409) [20:33:05] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.heritage/SAL [20:56:10] !log tools.lexeme-forms deployed fa8f5d87a4 (l10n updates) [20:56:13] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [21:24:33] !log bking@deployment-elastic09 starting ES6->7 upgrade in beta-cluster T315604 [21:24:34] inflatador: Unknown project "bking@deployment-elastic09" [21:24:34] T315604: Upgrade relforge cluster to 7.10.2 - https://phabricator.wikimedia.org/T315604 [21:25:32] !log deployment-prep ES6->7 upgrade in beta-cluster T315604 [21:25:36] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [21:34:32] https://openstack-browser.toolforge.org/ seems to be down. [21:38:00] seems to be working for me [22:06:13] it's often very slow [22:12:10] Same here, sometimes it responds as expected, sometimes it takes more than 30 sec for an refresh or change of view and thus looks like it were down