See T319953#9385479 for a synopsis of panoviewer's operation. Note that zoomviewer is very similar, and migrating it is tracked by T320210. Both tools have a PHP webservice which queues a job. The job runs a binary and writes the result to NFS. The jobs will both need a buildpack but the webservices don't need anything special except the ability to queue a job. The current plan is for the webservice to use a standard image, and for the job alone to use the buildpack.

Neither tool uses composer so it would increase the tool complexity to use a PHP library for queuing jobs, if such a library existed.

The work I've done on T319953 is already beyond what I would expect from a volunteer, and so I'm very much interested in simplifying the process, so that it continues to be feasible for these kinds of tools to be written and maintained by the community. So I think it should just work, one way or another.

If it's a problem to rebuild the images every time TJF is released, then you could install the packages on the host in a virtual environment, and bind-mount it into the container. In the container, have a wrapper in /usr/local/bin or modify the PATH.

Note that the container would need to get a client certificate somehow, ideally without relying on NFS.

I'd say that the quicker solution right now and more stable is just to make the call yourself from the lang you are using.

The call to create a job would be the equivalent of:

curl -v \
  -X POST \
  -H "content-type: application/json" \
  --data '{"name": "test", "imagename": "python3.11", "cmd": "env", "mount": "all"}' \
  --insecure \
  --cert $TOOLS_DATA_DIR/.toolskube/client.crt \
  --key $TOOLS_DATA_DIR/.toolskube/client.key \
  https://api.svc.tools.eqiad1.wikimedia.cloud:30003/jobs/api/v1/jobs/

It might take some time for us to provide an easier option (will happen, but might not be there before you have to move out of the grid).

Related: T321919: Figure out and document how to call the Kubernetes API as your tool user from inside a pod

In T356377#9506478, @dcaro wrote:

I'd say that the quicker solution right now and more stable is just to make the call yourself from the lang you are using.

I could make a shell script that works like toolforge-cli and have the tool run it, that'll make it easier to migrate to the real CLI once it is available.

--cert $TOOLS_DATA_DIR/.toolskube/client.crt \

There is no TOOLS_DATA_DIR environment variable. I tested it yesterday, it's broken. lighttpd is not passing arbitrary environment variables down to PHP.

In T356377#9508759, @tstarling wrote:

In T356377#9506478, @dcaro wrote:

I'd say that the quicker solution right now and more stable is just to make the call yourself from the lang you are using.

I could make a shell script that works like toolforge-cli and have the tool run it, that'll make it easier to migrate to the real CLI once it is available.

--cert $TOOLS_DATA_DIR/.toolskube/client.crt \

There is no TOOLS_DATA_DIR environment variable. I tested it yesterday, it's broken. lighttpd is not passing arbitrary environment variables down to PHP.

That should have been fixed :/ I did test it, let me recheck: T354320: [webservice] php 7.4 containers don't pass through the environment variables to the scripts

:facepalm: it's a typo, it's $TOOL_DATA_DIR, not $TOOLS_DATA_DIR, let me give you a tested curl example

It's OK, the container just hadn't been restarted since that task was fixed. I see the right environment now.

In T356377#9508767, @tstarling wrote:

It's OK, the container just hadn't been restarted since that task was fixed. I see the right environment now.

ack, btw. the above example works when using the right envvar :)

tools.wm-what@wm-what-59d64fb59c-q6wm9:~$ curl -v \
  -X POST \
  -H "content-type: application/json" \
  --data '{"name": "test", "imagename": "python3.11", "cmd": "env", "mount": "all"}' \
  --insecure \
  --cert $TOOL_DATA_DIR/.toolskube/client.crt \
  --key $TOOL_DATA_DIR/.toolskube/client.key \
  https://api.svc.tools.eqiad1.wikimedia.cloud:30003/jobs/api/v1/jobs/
...
{"name": "test", "cmd": "env", "image": "python3.11", "image_state": "stable", "filelog": "False", "filelog_stdout": null, "filelog_stderr": null, "status_short": "Unknown", "status_long": "No pods were created for this job.", "emails": "none", "retry": 0, "mount": "all"}

deleted comment -- sorry wrong task