I've got a django-based tool that I was previously running in test mode directly on the bastion hosts using runserver. Now I'm trying to move that over the kubernetes for production. I've got things to the point where I can bring up a pod and see the server start by watching uwsgi.log:
SIGINT/SIGQUIT received...killing workers... worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds goodbye to uWSGI. *** Starting uWSGI 2.0.18-debian (64bit) on [Sun Jan 12 05:28:38 2020] *** compiled with version: 8.2.0 on 10 February 2019 02:42:46 os: Linux-4.9.0-0.bpo.8-amd64 #1 SMP Debian 4.9.144-3.1~deb8u1 (2019-03-14) nodename: spi-tools-3688113665-jl049 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /data/project/spi-tools detected binary path: /usr/bin/uwsgi-core chdir() to /data/project/spi-tools/www/python/src your memory page size is 4096 bytes detected max file descriptor number: 65536 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :8000 fd 3 Python version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] PEP 405 virtualenv detected: /data/project/spi-tools/www/python/venv Set PythonHome to /data/project/spi-tools/www/python/venv *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x55ce19eedee0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 364600 bytes (356 KB) for 4 cores *** Operational MODE: preforking *** mounting /data/project/spi-tools/www/python/src/app.py on /spi-tools WSGI app 0 (mountpoint='/spi-tools') ready in 3 seconds on interpreter 0x55ce19eedee0 pid: 1 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 1) spawned uWSGI worker 1 (pid: 7, cores: 1) spawned uWSGI worker 2 (pid: 8, cores: 1) spawned uWSGI worker 3 (pid: 9, cores: 1) spawned uWSGI worker 4 (pid: 10, cores: 1)
which I assume means my server is actually up and running. But, how do I connect to it? What URL is it behind?
Never mind, I found it by trial-and-error. It's https://tools.wmflabs.org/spi-tools/ https://tools.wmflabs.org/spi-tools/
But, is that documented anywhere in the wiki?
On Jan 12, 2020, at 12:35 AM, Roy Smith roy@panix.com wrote:
I've got a django-based tool that I was previously running in test mode directly on the bastion hosts using runserver. Now I'm trying to move that over the kubernetes for production. I've got things to the point where I can bring up a pod and see the server start by watching uwsgi.log:
SIGINT/SIGQUIT received...killing workers... worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds goodbye to uWSGI. *** Starting uWSGI 2.0.18-debian (64bit) on [Sun Jan 12 05:28:38 2020] *** compiled with version: 8.2.0 on 10 February 2019 02:42:46 os: Linux-4.9.0-0.bpo.8-amd64 #1 SMP Debian 4.9.144-3.1~deb8u1 (2019-03-14) nodename: spi-tools-3688113665-jl049 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /data/project/spi-tools detected binary path: /usr/bin/uwsgi-core chdir() to /data/project/spi-tools/www/python/src your memory page size is 4096 bytes detected max file descriptor number: 65536 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :8000 fd 3 Python version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] PEP 405 virtualenv detected: /data/project/spi-tools/www/python/venv Set PythonHome to /data/project/spi-tools/www/python/venv *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x55ce19eedee0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 364600 bytes (356 KB) for 4 cores *** Operational MODE: preforking *** mounting /data/project/spi-tools/www/python/src/app.py on /spi-tools WSGI app 0 (mountpoint='/spi-tools') ready in 3 seconds on interpreter 0x55ce19eedee0 pid: 1 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 1) spawned uWSGI worker 1 (pid: 7, cores: 1) spawned uWSGI worker 2 (pid: 8, cores: 1) spawned uWSGI worker 3 (pid: 9, cores: 1) spawned uWSGI worker 4 (pid: 10, cores: 1)
which I assume means my server is actually up and running. But, how do I connect to it? What URL is it behind? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
You mean, that you just get the path determined by the name of your tool on the server? The tool creation form on toolsadmin does say "The tool name is used as part of the URL for the tool's webservice."
On Sun, 12 Jan 2020, 05:47 Roy Smith, roy@panix.com wrote:
Never mind, I found it by trial-and-error. It's https://tools.wmflabs.org/spi-tools/
But, is that documented anywhere in the wiki?
On Jan 12, 2020, at 12:35 AM, Roy Smith roy@panix.com wrote:
I've got a django-based tool that I was previously running in test mode directly on the bastion hosts using runserver. Now I'm trying to move that over the kubernetes for production. I've got things to the point where I can bring up a pod and see the server start by watching uwsgi.log:
SIGINT/SIGQUIT received...killing workers... worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds goodbye to uWSGI. *** Starting uWSGI 2.0.18-debian (64bit) on [Sun Jan 12 05:28:38 2020] *** compiled with version: 8.2.0 on 10 February 2019 02:42:46 os: Linux-4.9.0-0.bpo.8-amd64 #1 SMP Debian 4.9.144-3.1~deb8u1 (2019-03-14) nodename: spi-tools-3688113665-jl049 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /data/project/spi-tools detected binary path: /usr/bin/uwsgi-core chdir() to /data/project/spi-tools/www/python/src your memory page size is 4096 bytes detected max file descriptor number: 65536 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :8000 fd 3 Python version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] PEP 405 virtualenv detected: /data/project/spi-tools/www/python/venv Set PythonHome to /data/project/spi-tools/www/python/venv *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x55ce19eedee0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 364600 bytes (356 KB) for 4 cores *** Operational MODE: preforking *** mounting /data/project/spi-tools/www/python/src/app.py on /spi-tools WSGI app 0 (mountpoint='/spi-tools') ready in 3 seconds on interpreter 0x55ce19eedee0 pid: 1 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 1) spawned uWSGI worker 1 (pid: 7, cores: 1) spawned uWSGI worker 2 (pid: 8, cores: 1) spawned uWSGI worker 3 (pid: 9, cores: 1) spawned uWSGI worker 4 (pid: 10, cores: 1)
which I assume means my server is actually up and running. But, how do I connect to it? What URL is it behind? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
OK, I found where it's documented:
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Tool_Accounts#What_is_a... https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Tool_Accounts#What_is_a_Tool_Account?
"The ability to run a Web service which is visible at https://tools.wmflabs.org/<TOOL NAME>/"
I'm sure I read that at some point, but it got evicted from cache.
On Jan 12, 2020, at 4:45 AM, Alex Monk krenair@gmail.com wrote:
You mean, that you just get the path determined by the name of your tool on the server? The tool creation form on toolsadmin does say "The tool name is used as part of the URL for the tool's webservice."
On Sun, 12 Jan 2020, 05:47 Roy Smith, <roy@panix.com mailto:roy@panix.com> wrote: Never mind, I found it by trial-and-error. It's https://tools.wmflabs.org/spi-tools/ https://tools.wmflabs.org/spi-tools/
But, is that documented anywhere in the wiki?
On Jan 12, 2020, at 12:35 AM, Roy Smith <roy@panix.com mailto:roy@panix.com> wrote:
I've got a django-based tool that I was previously running in test mode directly on the bastion hosts using runserver. Now I'm trying to move that over the kubernetes for production. I've got things to the point where I can bring up a pod and see the server start by watching uwsgi.log:
SIGINT/SIGQUIT received...killing workers... worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds goodbye to uWSGI. *** Starting uWSGI 2.0.18-debian (64bit) on [Sun Jan 12 05:28:38 2020] *** compiled with version: 8.2.0 on 10 February 2019 02:42:46 os: Linux-4.9.0-0.bpo.8-amd64 #1 SMP Debian 4.9.144-3.1~deb8u1 (2019-03-14) nodename: spi-tools-3688113665-jl049 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /data/project/spi-tools detected binary path: /usr/bin/uwsgi-core chdir() to /data/project/spi-tools/www/python/src your memory page size is 4096 bytes detected max file descriptor number: 65536 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :8000 fd 3 Python version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] PEP 405 virtualenv detected: /data/project/spi-tools/www/python/venv Set PythonHome to /data/project/spi-tools/www/python/venv *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x55ce19eedee0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 364600 bytes (356 KB) for 4 cores *** Operational MODE: preforking *** mounting /data/project/spi-tools/www/python/src/app.py on /spi-tools WSGI app 0 (mountpoint='/spi-tools') ready in 3 seconds on interpreter 0x55ce19eedee0 pid: 1 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 1) spawned uWSGI worker 1 (pid: 7, cores: 1) spawned uWSGI worker 2 (pid: 8, cores: 1) spawned uWSGI worker 3 (pid: 9, cores: 1) spawned uWSGI worker 4 (pid: 10, cores: 1)
which I assume means my server is actually up and running. But, how do I connect to it? What URL is it behind? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org mailto:Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org mailto:labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud https://lists.wikimedia.org/mailman/listinfo/cloud
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org mailto:Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org mailto:labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud https://lists.wikimedia.org/mailman/listinfo/cloud_______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
https://tools.wmflabs.org/spi-tools
On Sun, 12 Jan 2020, 05:36 Roy Smith, roy@panix.com wrote:
I've got a django-based tool that I was previously running in test mode directly on the bastion hosts using runserver. Now I'm trying to move that over the kubernetes for production. I've got things to the point where I can bring up a pod and see the server start by watching uwsgi.log:
SIGINT/SIGQUIT received...killing workers... worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds goodbye to uWSGI. *** Starting uWSGI 2.0.18-debian (64bit) on [Sun Jan 12 05:28:38 2020]
compiled with version: 8.2.0 on 10 February 2019 02:42:46 os: Linux-4.9.0-0.bpo.8-amd64 #1 SMP Debian 4.9.144-3.1~deb8u1
(2019-03-14)
nodename: spi-tools-3688113665-jl049 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /data/project/spi-tools detected binary path: /usr/bin/uwsgi-core chdir() to /data/project/spi-tools/www/python/src your memory page size is 4096 bytes detected max file descriptor number: 65536 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :8000 fd 3 Python version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] PEP 405 virtualenv detected: /data/project/spi-tools/www/python/venv Set PythonHome to /data/project/spi-tools/www/python/venv *** Python threads support is disabled. You can enable it with
--enable-threads ***
Python main interpreter initialized at 0x55ce19eedee0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 364600 bytes (356 KB) for 4 cores *** Operational MODE: preforking *** mounting /data/project/spi-tools/www/python/src/app.py on /spi-tools WSGI app 0 (mountpoint='/spi-tools') ready in 3 seconds on interpreter
0x55ce19eedee0 pid: 1 (default app)
*** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 1) spawned uWSGI worker 1 (pid: 7, cores: 1) spawned uWSGI worker 2 (pid: 8, cores: 1) spawned uWSGI worker 3 (pid: 9, cores: 1) spawned uWSGI worker 4 (pid: 10, cores: 1)
which I assume means my server is actually up and running. But, how do I connect to it? What URL is it behind? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud