-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes required for Jupyter-Scheduler integration #1832
Conversation
We need some people to test this out, before including it in a release. |
conda-store-environments = var.conda-store-environments | ||
default-conda-store-namespace = var.conda-store-default-namespace | ||
conda-store-cdsdashboard-token = module.kubernetes-conda-store-server.service-tokens.cdsdashboards | ||
conda-store-argo-workflows-jupyter-scheduler-token = module.kubernetes-conda-store-server.service-tokens.argo-workflows-jupyter-scheduler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
passing token so it can be set on jupyter user pods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is jupyter scheduler a pod that runs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jupyter-Scheduler is a lab extension that runs while the user pod is running. Getting access to view the conda-store makes it so we can more reliably set the path for the conda-store environments (mostly for this function).
The conda-store feature is also a traitlet, albeit just a basic toggle.
.../template/stages/07-kubernetes-services/modules/kubernetes/services/jupyterhub/configmaps.tf
Show resolved
Hide resolved
...s-services/modules/kubernetes/services/jupyterhub/files/jupyter/jupyter_server_config.py.tpl
Show resolved
Hide resolved
ADMIN = "admin" | ||
DEVELOPER = "developer" | ||
ANALYST = "analyst" | ||
|
||
base = "argo-" | ||
|
||
if ANALYST in groups: | ||
argo_sa = base + "view" | ||
if DEVELOPER in groups: | ||
argo_sa = base + "dev" | ||
if ADMIN in groups: | ||
argo_sa = base + "admin" | ||
else: | ||
return {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit clunky, plus we might get rid of analyst, dev, and admin. Not sure if there's a better way. Maybe check the individual argo permissions of the groups themselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree! The difficult part is that roles
aren't available in the current spawner.user.auth_state
. I think the other alternative is to perform a keycloak API call. We would probably also need to add keycloak secrets to the hub
deployment.
I have this particular enhancement in this issue.
"ARGO_TOKEN": { | ||
"valueFrom": { | ||
"secretKeyRef": { | ||
"name": f"{argo_sa}.service-account-token", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did the modifications you made create this token or did it already exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This token already exists, it's the default argo-admin
, argo-dev
and argo-view
secrets. I'm not entirely sure if they were being used prior to this... The ARGO_TOKEN used when someone creates a workflow from the UI (and the one that can be copied from there) are not the same as any of those above.
I have also included this the enhancements issue, namely, the ability to create short-lived tokens on a per user basis.
|
||
def profile_conda_store_viewer_token(): | ||
return { | ||
"CONDA_STORE_TOKEN": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any way this token could be misused by the user? It's used by ARGO_WORKFLOWS_EXECUTOR, I see - https://github.com/search?q=repo%3Anebari-dev%2Fargo-workflows-executor+CONDA_STORE_TOKEN&type=code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Argo Workflows Executor a package that's installable or a pod that's running or its included on the jupyterhub pod?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This token is view-only in scope so if the user was motivated enough, they could view all of the namespaces/environments that exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later down the road we should scope this token to just what the user can see. But for now this works.
|
||
data = { | ||
"conda-store-api-token" = var.conda-store-argo-workflows-jupyter-scheduler-token | ||
"conda-store-service-name" = var.conda-store-service-name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a url I guess. I want to double check this later and make sure there's not a better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this is an internal service url. conda-store-service-name
, as a variable name, is used elsewhere in the other services so I just kept the same name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing controversial here to me. I like the changes. @iameskild and @Adam-D-Lewis has this PR been tested with a deployment?
...ri/template/stages/07-kubernetes-services/modules/kubernetes/services/argo-workflows/main.tf
Outdated
Show resolved
Hide resolved
|
||
def profile_conda_store_viewer_token(): | ||
return { | ||
"CONDA_STORE_TOKEN": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later down the road we should scope this token to just what the user can see. But for now this works.
Reference Issues or PRs
Closes #1755
This PR makes several modifications that are required for Jupyter-Scheduler to work with Nebari, specifically the Argo-Workflows extension that I built. A few additional changes were also required on the Nebari-Workflow-Controller side; see PR 16.
The main changes include:
jupyter_notebook_config
tojupyter_server_config
and enablingjupyter_server.serverapp.ServerApp
on JupyterHub - these changes are required for Jupyter Scheduler to work with our current version of JupyterHub.admin
,developer
orviewer
) which means that only users with Argo admin and developer roles will be allowed to submit jobs.What does this implement/fix?
Put a
x
in the boxes that applyTesting
Any other comments?