[08:35:48] hi all, I have just receive a message about a puppet failure, but I do not know what to do with it [08:35:53] nor where to report it [08:36:29] [Cloud VPS alert][wcdo] Puppet failure on wcdo02.wcdo.eqiad1.wikimedia.cloud (172.16.0.140) [08:36:46] ---- Failed resources if any: [08:36:46] * Exec[create-volume-group] [08:36:47] * Exec[available-space-second-local-disk] [08:38:23] CristianCantoro: here is the right place to seek help [08:38:37] yay! :-D [09:00:53] So, one reason for the puppet failing is that I mounted a volume to a VPS, to make a backup (we need to upgrade the VPS), I made the backup, detached the volume and attached to new server. I modified `/etc/fstab` manually on the new server to attach the volume. I did not see any instruction to do this automatically, and I assume I need to run [09:00:54] `wmcs-prepare-cinder-volume` only once [09:09:01] !log tools.bridgebot Double IRC messages to other bridges [09:09:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL [09:14:15] CristianCantoro: someone will be with you soon to help [09:24:04] CristianCantoro: those puppet warning emails are happening because you have configured all of your project instances (Puppet -> Project Puppet in horizon) to use the "role::labs::lvm::srv" class, but that doesn't work with instances that use the new cinder volume system [09:24:45] so you can move that class to the old VM, the wmcs-prepare-cinder-volume command configures the new system by itself [10:15:36] taavi: I removed the role from uppet -> Project Puppet, but how do I apply it to the old server only? [10:16:10] 'puppet' tab in the instance details [10:33:02] taavi: ok, it has it [10:39:10] taavi: thank you [13:17:41] taavi: could you have a look at this patch? https://gerrit.wikimedia.org/r/c/cloud/toolforge/jobs-framework-api/+/820078 [13:45:31] dhinus: i'd maybe not set the old image as deprecated quite yet, but otherwise looks good [13:50:41] yeah I was unsure about that, what's exactly the impact/ [13:50:44] ? [13:50:55] maybe we can do it later in a separate patch? [13:54:11] Node 12 EOL was last April, so ideally we shouldn't keep it around for too long [14:18:12] lol [14:18:26] we're still using it in production :) [14:23:00] LOL, thinking ahead... :D [14:24:28] Getting rid of node12 is noble, but python2 and php5.3 are probably more urgent. ;) [14:24:59] dhinus: pretty much only a cosmetic thing [14:25:07] wm-bb: agreed ;) [14:25:17] the usual argument around here is that debian supports it so we don't need to care about upstream EOLs :-P [14:25:36] fair enough :P [14:26:22] I don't have a strong preference either way, so I'll remove the "-DEPRECATED" suffix for now [14:26:24] how much longer 'till that runs out [14:26:53] bullseye has 2 years of normal and 4 years of LTS support remaining IIRC [14:28:15] patch updated [14:28:21] looks good! [14:29:05] also apols, I meant to start this whole conversation in #wikimedia-cloud-admin and instead wrote here by mistake :) [14:29:57] taavi: do you want to +2 this or should I +2 myself? [14:31:50] feel free to +2 yourself when deploying [14:34:38] do I need to deploy the jobs-api manually? [14:35:11] (moving over to #wikimedia-cloud-admin ...) [15:46:05] !log toolsbeta recreated jobs-api pods to pick up new ConfigMap [15:46:07] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Toolsbeta/SAL [15:51:35] !log tools recreated jobs-api pods to pick up new ConfigMap [15:51:37] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [15:54:01] !log wlm-it-visual test please ignore this [15:56:20] . (re @wmtelegram_bot: hmmm... yeah !log messages currently will not be seen by stashbot when started from the telegram side. This is because t...) [15:58:31] Yup T314505 [17:59:37] Is there no expectation of privacy on Cloud VPS the way there is on Toolforge? [18:00:21] @harej: can you rephrase that question? I'm not sure I understand what you are asking about. [18:05:25] The way there is no expectation of privacy on Toolforge, I mean. I am looking into setting up an open source app on a Cloud VPS, but its primary authentication scheme is based on email addresses. Putting aside that Wikimedians shouldn't have to provide an email address, would it also be an inherently bad idea even if this email address is stored in a database and not otherwise exposed? [18:07:56] (Email addresses are not validated as far as I can tell so my proposed workaround is to encourage people to use fake email addresses based on usernames) [18:12:46] @harej: It sounds like would apply. And email addresses would certainly be considered PII that you are collecting. [18:14:16] (there is ongoing work to make all of the TOU more clear and consistent, but things involving legal council seem to move even slower than things involving software engineers) [18:15:16] Lawyers as an institution are legendarily slow. At least software engineers automate stuff. [19:33:15] !log tools.lexeme-forms deployed a11b6a55f6 (l10n updates) [19:33:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [20:19:35] I just filed T314527. [20:19:36] T314527: Toolforge root for LucasWerkmeister - https://phabricator.wikimedia.org/T314527 [20:23:39] :o [20:35:10] On the topic of maintaining your own authentication database, my recommendation is: don't. [20:36:04] Auth is notoriously difficult to do right. I certainly don't want to be responsible for keeping somebody else's email and password secure. [20:37:48] I would use https://wikitech.wikimedia.org/wiki/OAuth. That way, you dump all the responsibility for keeping that PII secure onto the WMF folks who run the production servers. OAuth is a bit confusing to figure out if you've never done it before, but IMHO, the benefits more than justify the complexity. [20:58:58] * andrewbogott does the qdel [21:04:36] !log wm-bot manually fix nicks via telnet [21:04:38] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wm-bot/SAL [21:53:08] There are plenty of things on Cloud infrastructure which store email addresses, including Wikimedia Space which used to be semi-official. If you are deciding on an authentication scheme now, you should use OAuth / OIDC. If you want to install an application which has emails as primary identifiers wired into it, I don't think there's a better solution than just accepting that. [21:54:26] The Cloud docs say otherwise but I don't think they have kept up with reality (which is that between forcing people to use some third-party hosting platform with zero community control over it, and storing some low-value PII on the Cloud servers, the second is always going to be better for user privacy.) [21:55:43] (Or maybe they don't say otherwise, the ToU doesn't seem to.) [23:05:23] Baserow, which is what I want to install, *has* a plugin interface but no off-the-shell OAuth implementations. I would have to make my own. [23:06:43] And as you correctly point out, the alternative is sending users to a third-party server, where you probably won't get away with a fake email address [23:27:29] harej: you could probably make the app use usernames relatively easily by automatically appending to the input field something like @actually-an-username..wmflabs.org [23:38:27] I'm wary of making too many customizations since I'll be on the hook for keeping those changes in sync with new versions of the software [23:39:08] At minimum there would be a notice encouraging people to use a fake email address in a certain format [23:46:57] which software is it? [23:49:17] https://baserow.io/