Talk:News/2020 Kubernetes cluster migration

From Wikitech
Jump to navigation Jump to search

Why does `which kubectl` not follow aliases?

I am wondering why this does not seem to work:

tools.ordia@tools-sgebastion-07:~$ alias kubectl=/usr/bin/kubectl
tools.ordia@tools-sgebastion-07:~$ which kubectl
/usr/local/bin/kubectl

Shouldn't the last line be "/usr/bin/kubectl". It seems that it sets the correct version:

tools.ordia@tools-sgebastion-07:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:20:18Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079",   GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
tools.ordia@tools-sgebastion-07:~$ /usr/bin/kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:20:18Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
tools.ordia@tools-sgebastion-07:~$ /usr/local/bin/kubectl version
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.12", GitCommit:"19e81afecf5eb2b7838c35e2cbf776aff04dc34c", GitTreeState:"clean", BuildDate:"2017-04-20T21:01:06Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

My understanding of "which" must be wrong. — Finn Årup Nielsen (fnielsen) (talk) 16:37, 10 January 2020 (UTC)

There is a reasonable explanation of how which works and why you are surprised at https://unix.stackexchange.com/a/10529/10171 --BryanDavis (talk) 17:51, 10 January 2020 (UTC)

"webservice migrate" cannot find public_html

Running "webservice migrate" I get the following output for a Python-based webservice:

   DEPRECATED: 'php5.6' type is deprecated.
     See https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes
     for currently supported types.
   Stopping webservice on legacy Kubernetes cluster
   Switched to context "toolforge".
   Could not find a public_html folder or a .lighttpd.conf file in your tool home.

The tool I am try to work on is Scholia. There is no public_html folder (there is something in ~/www/python). I have no .lighttpd.conf. — Finn Årup Nielsen (fnielsen) (talk) 08:22, 21 February 2020 (UTC)

A Phabricator task: https://phabricator.wikimedia.org/T245814 We are also tracking this at Scholia's issue page: https://github.com/fnielsen/scholia/issues/1013Finn Årup Nielsen (fnielsen) (talk) 10:37, 21 February 2020 (UTC)

It apparently works now. I think was due to our tool (import error on lxml on new server) as well as the problem with virtual environment change during migration. — Finn Årup Nielsen (fnielsen) (talk) 10:46, 21 February 2020 (UTC)

I think there may be a bug in the webservice migrate command. I got this same error when migrating the 'account-creation' tool which is also a python webservice. I will be attempting to recreate in a controlled environment. --BryanDavis (talk) 21:40, 24 February 2020 (UTC)
After some additional investigation I have found that it is somehow possible for a tool to be running on the legacy Kubernetes cluster without a "web: ..." entry in the tool's $HOME/service.manifest file. This seems to be the cause of webservice migrate trying to start a webservice of the default (and deprecated) 'php5.6' type. I have added code in the forced migration script to look for this problem and report an error rather than migrating these tools incorrectly. For now my intent is to manually update the service.manifest files for tools found in this state and then migrate them. --BryanDavis (talk) 19:52, 25 February 2020 (UTC)