remote-run api implementation #4022
Conversation
| :param int max_duration: maximum allowed duration for the remote-ruh job | ||
| :return: outcome of the operation, and resulting Kubernetes pod information | ||
| """ | ||
| kube_client = KubeClient(config_file="/etc/kubernetes/admin.conf") |
There was a problem hiding this comment.
how come we're not using the KUBECONFIG env var that's set in the paasta-api unit? (i.e., Environment=KUBECONFIG=/var/lib/paasta/api/paasta-api.conf)
There was a problem hiding this comment.
The paasta-api role that we currently have set up does not have the permissions to do all the required action, so I was battled between doing this, and starting to assign more permissions to paasta-api. I picked this way cause it's easier to ship, as we can remove permission issues from the equation.
There was a problem hiding this comment.
this would block running this code locally as this kubeconfig only exists on the paasta control plane and not devboxes - if this is temporary (and we'll give the paasta-api user the correct permissions later) then this is fine, but if we want something permanent we should update the paasta-api permissions
Yes, I'm looking into the clean up logic separately. |
Clean up logic for the (meant to be) ephemeral resources which are created in remote-run invocations (#4022).
Clean up logic for the (meant to be) ephemeral resources which are created in remote-run invocations (#4022).
This was meant to be included in the last release but I (luisp) don't know how to read and merged things in the "wrong" order. This correctly merges in the following PRs: * cleanup for remote-run resources (#4024) Clean up logic for the (meant to be) ephemeral resources which are created in remote-run invocations (#4022). * new remote-run cli (#4025) Last portion of #3986, with the updated logic to reflect the updated API conventions introduced in #4022.
This is the largest portion of #3986, implementing the new API for remote-run (look at the second commit, the first is mostly codegen stuff).
I deviated a bit from the original design poc code, as I saw that was waiting for the remote-run pods to become available as part of the
remote_run/.../startendpoint, and that's not a great idea as it would just keep one API worker busy doing nothing. So I modified that endpoint to return as soon as the job resource is created, and then added another one to allow the CLI client to poll for updates until the pod becomes available.So in summary the logic is the following:
I also refused to add more stuff to the
kubernetes_toolsmodule as that already has 4500+ lines in it, which is too much for me not to get triggered about, so I grouped all the new methods needed in a new module underpaasta_tools.kubernetes