[05:15:14] !log grantreview Replaced grantreview-03 with grantreview-04 (T236542) [05:15:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Grantreview/SAL [05:15:17] T236542: "grantreview" Cloud VPS project jessie deprecation - https://phabricator.wikimedia.org/T236542 [05:26:57] !log redirects Removed Rush as project member (T236537) [05:27:00] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects/SAL [05:27:00] T236537: "redirects" Cloud VPS project jessie deprecation - https://phabricator.wikimedia.org/T236537 [05:30:25] !log redirects Building redirects-nginx02 (T236537) [05:30:27] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects/SAL [06:08:23] !log redirects Deleted and recreated web proxies to point to redirects-nginx02 (T236537) [06:08:35] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects/SAL [06:08:37] T236537: "redirects" Cloud VPS project jessie deprecation - https://phabricator.wikimedia.org/T236537 [06:10:01] !log redirects Deleted redirects-nginx01 (T236537) [06:10:03] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects/SAL [11:10:24] !log tools Built and pushed python37 docker image based on buster (T230961) [11:10:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [11:10:28] T230961: Install a version of Python newer than 3.5.3 in Toolforge - https://phabricator.wikimedia.org/T230961 [13:22:11] How can I reset the password of my Wikimedia developer account? I'm actually not even sure I have one already, but when I tried to register, I got the error message that my username is already taken. And I had one in like 2014 when it was still called tool labs. [13:24:11] metadoi: have you tried resetting your password (via email)? [13:25:50] phamhi: where? on https://toolsadmin.wikimedia.org/auth/login/ there is only a login form, no way to reset via email (at least I found none) [13:26:39] oh ok..I thought you were referring to this: https://www.mediawiki.org/wiki/Developer_account [13:27:44] I actually don't know the difference, I can try it there [13:28:00] try this one: https://wikitech.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page [13:28:22] there's a "Forgot your password" link [13:30:44] phamhi: many thanks! that worked perfectly [13:31:07] cool..out of curiousity..which link did you use? [13:37:50] what do you mean which link? To reset? [13:37:56] yup [13:38:30] the one one provided on wikitech using the "Forgot your password" [13:38:39] ah ok.. good to know [13:39:08] This link would've been nice to have on https://toolsadmin.wikimedia.org/auth/login/ :) [13:39:51] but anyway, glad it works now [13:40:38] agreed..let me see if we can put in a request for taht [14:45:19] !log tools Built and pushed php73 docker image based on buster (T230961) [14:45:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [14:45:22] T230961: Install a version of Python newer than 3.5.3 in Toolforge - https://phabricator.wikimedia.org/T230961 [14:45:30] !log tools Built and pushed jdk11 docker image based on buster (T230961) [14:45:33] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [14:45:39] !log tools Built and pushed golang111 docker image based on buster (T230961) [14:45:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [14:45:49] !log tools Built and pushed ruby25 docker image based on buster (T230961) [14:45:51] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [15:07:10] bd808: Are SSH keys uploaded to toolsadmin.wikimedia also automatically added to Gerrit or do you need to add them separately? [15:07:56] They won't be automatically uploaded to gerrit [15:08:54] Since if they were you'll be getting an email letting you know the key was added to your account :P [15:10:02] paladox: That's why I asked. Because I uploaded a second key to toolsadmin and I thought they were automatically added to Gerrit as well, but that didn't happened. [15:10:12] and I thought they did [15:10:47] no, no connection between the ssh keys used for authentication to Cloud VPS and the ssh keys used for authentication to Gerrit [15:19:33] bd808: Alright then. Thanks for clarifying :) [15:19:47] Thinking about it, kind of makes sense [17:35:18] !log tools.integraality Deploy latest from Git master: 471deddd (T237182) [17:35:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [17:35:32] !log tools.integraality Deploy latest from Git master: 588dae8 [17:35:33] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [17:46:08] !log tools.integraality Deploy latest from Git master: d0f4222 (T237189) [17:46:11] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [18:19:23] hi [18:19:31] has anyone encountered this [18:19:41] ``` [18:19:41] /data/project/wikiloop/www/js $ webservice --backend=kubernetes nodejs shell [18:19:41] Traceback (most recent call last): [18:19:41] File "/usr/bin/webservice", line 203, in [18:19:41] job.shell() [18:19:42] File "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/kubernetesbackend.py", line 502, in shell [18:19:42] 'interactive' [18:19:43] File "/usr/lib/python2.7/subprocess.py", line 710, in __init__ [18:19:43] errread, errwrite) [18:19:44] File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child [18:19:44] raise child_exception [18:19:45] OSError: [Errno 2] No such file or directory [18:19:45] ``` [18:28:06] xinbenlv: I haven't… do you happen to know if it happens with other tools as well? [18:29:17] Not sure why [18:29:47] hm, I just tried and it seems to work for me [18:29:53] anyway, it turns out the current Toolforge Kubernates still only supports nodejs up to v6.0~ish. My nodejs app can't run on Toolforge. I will have to run on VPS probab,y [18:35:21] xinbenlv: you can bring your own nodejs with NVM [18:35:36] (or another node version manager) [18:36:01] https://phabricator.wikimedia.org/T237297 [18:36:34] I can try, but I doubt it, if NVM in the Toolforge Kubernetes can bring the latest NVM, then why Toolforge Kubernetes only supports v6.... [18:37:17] it does work with NVM on any node version [18:37:21] Last time I check, the Kubernetes version is yet too late, certain k8s images are not supported... I can try again [18:40:09] ``` [18:40:09] /data/project/wikiloop $ kubectl get pods [18:40:09] bash: kubectl: command not found [18:40:09] ```` [18:44:47] I don't quite recommend using k8s directly as it is an old version on toolforge atm. But there is a node10 container image you can use or you can use any image and NVM to get any nodejs version [18:51:46] I see [18:51:51] xinbenlv: I replied on your phabricator task, but for the sake of folks watching irc and not that task: `webservice --backend=kubernetes node10 [start|stop|shell]` [20:38:22] Thank you [20:39:17] +bd808, the next question would be, the tutorial suggests putting code into `www/js`, where is this configured? Can I put it elsewhere? If this is a k8s configuration, where can I find the config yaml? [20:54:41] xinbenlv: the $HOME/www/js location is hard coded into the system. You can use symlinks to actually map that into some other location if needed. This is the relevant software config -- https://github.com/wikimedia/operations-software-tools-webservice/blob/3149cf4283234de8dcdcf63de93fc420438209a6/toollabs/webservice/services/jswebservice.py#L17-L27 [20:58:41] Thank you, and does the webservice support custom k8s image? [20:58:47] no [20:59:17] that is on our wishlist for the future, but for now "bring your own container" is not possible [21:00:08] and honestly, "bring your own container" is not too likely for quite a while, but we may get to something in between that allows crating custom images from a base we maintain in 9-12 months. [21:00:35] I see [21:00:51] The Kubernetes cluster in Toolforge is not "plain" Kubernetes. Most images would not run on it properly today [21:01:04] next question: who has access to the `www/js` folder? what's the best way to supply credentials? [21:02:02] you can make the directory readable only by your tool account and place "secrets" in config files there or you can make a config file that is readable only by your tool to do the same [21:03:36] ok, but the kubernetes service will also be run under tool account right? [21:37:24] xinbenlv: correct. The pods will run as your tool user [21:55:31] !log admin deleting a ton of wikitech hiera pages that were either no-ops or refer to nonexistent VMs or prefixes [21:55:34] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [22:12:58] +bd808: thanks for your answer. now my next question will be, toolforge doesn't support custom domain nor root path [22:13:12] correct [22:14:24] +bd808: thanks for your answer. now my next question will be, toolforge doesn't support custom domain nor root path `/` rather than `tools.wmflabs.org/`, right? [22:14:24] root path is a "coming soon" feature (2-4 months). Custom domain is not likely to happen in the foreseeable future [22:15:28] correct. The URL scheme for Toolforge is https://tools.wmflabs.org/ and it is not configurable in any way today [22:15:56] the "coming soon" feature will be a migration to https://.toolforge.org/ for all tools [22:16:18] cool. but it seems our current configuration does not support subpath in our app [22:16:22] can we apply for a VPS? [22:16:51] bd808: no .wmflabs.org instead? [22:17:00] I hope you keep redirects in place [22:17:09] xinbenlv: what do you mean technically by "does not support subpath in our app"? [22:17:18] from wmflabs.org/$tool to $tool.toolforge.org [22:17:31] hauskater: we will support redirects of existing tools at the time of the change to the new URLs [22:17:39] :D [22:17:45] hauskater: not my first time rolling out new URL schemes ;) [22:18:04] I'm sure about that, but it'd be surely the first time for me [22:18:09] hauskater: we still do redirects for toolserver.org [22:18:14] I was already heading for Xanax lol [22:18:30] I don't think I understand... [22:19:57] xinbenlv: your application is "mounted" at https://tools.wmflabs.org/wikiloop. What happens after that is up to your source code. You said "does not support subpath in our app" which I interpret as a restriction in the code you have written [22:21:01] Yes, can we have something like `wikiloop.toolforge.org` instead of `https://tools.wmflabs.org/wikiloop` ? [22:21:38] xinbenlv: today, no. In 2-4 months when we roll out the new toolforge.org domain, yes. [22:21:53] I see [22:22:08] In that case is it ok if we apply for VPS? [22:22:17] until when new toolforge.org is available? [22:22:43] xinbenlv: you can apply, but honestly if the only reason is that you do not like the URL that's a poor one [22:23:18] why.... [22:24:21] I actually don't intend to apply for a VPS. The main reason is that IP address of AWS is blocked for even login users. I don't know what's the best way to petition to remove it at least for login users.... [22:24:40] they probably won't remove it [22:25:12] yeah, it's even harder to convince them to remove it. And even if global admins agree, I doubt if EN admins will [22:25:20] it might be possible to put your app behind an HTTP proxy that handles the extra part of the path transparently? [22:25:21] xinbenlv: That's a question for the wikis, and not something I can help you with [22:26:08] +Krenair, thanks for advice, I think that's what their policy are trying to block for (any proxies) [22:27:13] +bd808, yeah, I understand you don't try to context the policies on wiki. I am just saying, because of that policy and they toolforge.org has yet to rollout the rootpath feature, during the time can we apply for VPS in the meanwhile? [22:28:30] I understand you don't try to context the policies on wiki. '''context'''->'''contest''' [22:29:42] you can apply [22:30:04] xinbenlv: the only "feature" you would get with a Cloud VPS project is a slightly different URL as far as I understand it. Do you really want to own maintaining a full server just for that? [22:30:19] it seems like a bad use of your time and ours to me honestly [22:31:21] There are many other benefits too, e.g. the other benefit is that we want to automatic the release process including Continuous Integration so that when developers contributes in a easier way. [22:40:21] paladox: I'm in the process of finishing off the last remnants of puppet config on wikitech. Would you be willing/able to move the configs in https://wikitech.wikimedia.org/wiki/Hiera:Gerrit and https://wikitech.wikimedia.org/wiki/Hiera:Phabricator over to Horizon? [22:40:40] yeh [22:40:50] (and, Krenair, same question to you re: https://wikitech.wikimedia.org/wiki/Hiera:Deployment-prep and related instance pages) [22:40:57] * paladox does [22:41:14] paladox: thanks! Go ahead and delete the wikitech pages when you're done, so I know what's left [22:41:25] andrewbogott, yes, though I don't remember which one takes precedence [22:41:32] i doin't think i can delete andrewbogott [22:41:44] paladox: ok, just ping me then and I'll do it [22:41:49] Krenair: good question, let me check [22:41:55] Krenair: I think the the Hiera namespace "wins" [22:42:12] so [22:42:12] ok [22:42:24] any case where a key is in both files, we take the one from wikitech [22:42:45] andrewbogott oh! https://wikitech.wikimedia.org/wiki/Hiera:Gerrit can be deleted as the project should have been deleted i think? [22:42:49] i just need to do https://wikitech.wikimedia.org/wiki/Hiera:Phabricator [22:43:06] Krenair: that sounds right to me... [22:43:08] https://www.irccloud.com/pastebin/YK98v62T/ [22:43:29] where I think 'nu' is 'hiera in operations/puppet and operations/private' [22:43:37] httpyaml was encapi/horizon, mwyaml was wikitech, nuyaml is git [22:43:38] so it goes: git, wikitech, horizon [22:43:51] I mean, in search order [22:44:00] paladox: that's an easy one! I'll delete the gerrit page [22:44:02] so [22:44:08] git wins, then wikitech, then horizon? [22:44:25] so if we're taking wikitech out of the mix, wikitech keys win? [22:44:32] I think that horizon clobbers wikitech, which clobbers git [22:44:35] when they go into horizon [22:44:36] in case of a conflict [22:44:52] but we can test [22:45:55] * andrewbogott tries to think of a good, noisy key to test with [22:46:56] andrewbogott i think https://wikitech.wikimedia.org/wiki/Hiera:Phabricator can be deleted now [22:47:00] i've ported it to horizion [22:47:04] great! [22:47:05] thank you [22:47:10] your welcome :) [22:51:38] andrewbogott, maybe something with a custom puppetmaster and a special class that just spits out a notice with whatever you put in a parameter? [22:51:50] yep, writing that now [22:52:21] I did a bunch of grepping and came up with no existing solution [22:54:27] https://www.irccloud.com/pastebin/keFoSD2D/ [22:55:37] nice [22:55:49] First, set on Horizon but not wikitech... [22:55:50] Notice: It came from: horizon [22:56:55] set in both horizon and wikitech... [22:57:08] Notice: It came from: horizon [22:57:12] And, set on just wikitech... [22:58:10] hm... [22:58:23] it's not picking up wikitech, which means that last test isn't valid [22:58:26] * andrewbogott pokes more [23:00:33] thanks @jeh [23:02:40] ok, I just gave the page the wrong name [23:02:46] now, set on wikitech and not horizon: [23:02:46] Notice: It came from: wikitech [23:03:25] and, when set in both places... [23:04:00] Notice: It came from: horizon [23:04:09] So, resolved, Krenair, Horizon wins [23:04:12] okay [23:04:18] so [23:04:25] we take the keys from wikitech that aren't already set in horizon [23:04:31] and put those in horizon [23:04:39] then we blank the wikitech page [23:05:17] yep [23:06:34] and then when there are no hiera pages left we remove the namespace [23:07:37] Yeah [23:08:29] Or, alternately, blank out the pages but keep them, make the namespace read/only with a banner (If preserving the ability to read the history is useful…) [23:08:46] sure [23:09:08] once we stop reading into puppet from them we can remove the access control and that's the bit that matters right? [23:09:22] right [23:11:33] by the looks of things beta has 85 keys [23:12:08] wonder which of them we still care about [23:13:06] I'm running into a lot of keys that aren't read by anything anymore [23:13:15] and config for VMs that don't exist (but I deleted all of those I think) [23:15:15] well that's partially going to be because project admins can't delete those pages :P [23:15:33] guess we could blank them, but meh [23:18:32] * andrewbogott taking a copy-and-paste break [23:22:18] wow andrewbogott - nice cleaning on Wikitech [23:24:18] there's a lot left [23:24:38] godspeed [23:25:05] Makes sense to have those in just one place [23:43:46] andrewbogott, the 4 subpages of Hiera:Deployment-prep can be deleted