Allow using existing different namespaces for different users

[praveen-kanamarlapudi]

Proposed change

As of now, kubespawner uses one namespace for all user pods. It'll be great to allow using different namespaces based on the username. So users can do additional things in their namespaces (attaching existing PVCs in the namespaces ..etc)

Alternative options

NA

Who would use this feature?

Lot of enterprises will benefit from this feature as allocating different namespaces to different teams is a common practice in kubernetes and resources in existing namespaces can be effectively used.

Suggest a solution

It will be great if we can given an option to change the namespace based on the username in the pre_spawn_hook or any other equivalent.

Sample Code:

from subprocess import check_call
def my_hook(spawner):
    username = spawner.user.name
    spawner.namespace = "dev_namespace" if username == "dev_user" else "prod_namespace"

c.Spawner.pre_spawn_hook = my_hook

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[manics]

There's an open PR to add a multi-namespace spawner: https://github.com/jupyterhub/kubespawner/pull/387

It includes a get_user_namespace method. I think you could override it in a local subclass (could be done inline in the config file), which should cover your usecase?

[praveen-kanamarlapudi]

Thanks @manics. So we can override get_user_namespace to return the namespace we want, I think it will cover our usecase.

[athornton]

I've done another PR: https://github.com/jupyterhub/kubespawner/pull/458

This lets you turn on enable_user_namespaces (or use a convenience subclass) and customize a namespace template. It will create the namespace if they don't exist (obviously Hub needs ClusterRoles/Bindings for this).

[athornton]

You will also (if you are enabling use_user_namespaces) want to put something like this in your jupyterhub_config.py:

   def get_hub_ns():
        ns_path = '/var/run/secrets/kubernetes.io/serviceaccount/namespace'
        if os.path.exists(ns_path):
            with open(ns_path) as f:
                return f.read().strip()
        return 'default'

h_ns = get_hub_ns()
    c.JupyterHub.hub_connect_url = f"http://hub.{h_ns}:{os.environ['HUB_SERVICE_PORT']}"

This just lets the hub connect URL work across multiple namespaces.

[TiPPeX2]

@praveenkanamarlapudi I'm also facing the same use case, we want to create pods per namespace(which is equal to a group of users) I added namespace selection in the form, and changed the spawner namespace to the selected namespace.

This worked, but it threw exception on missing serviceaccount on that namespace. error looking up service account <NAMESPACE_CHOOSEN>/<SERVICE_ACCOUNT_NAME>: serviceaccount \"<SERVICE_ACCOUNT_NAME>\" not found"

did you create a serviceaccount on all desired namespaces? I don't understand the logic being it, why would I must have a serviceaccount under each namespace?

P.S I saw in docs: This serviceaccount must already exist in the namespace the user pod is being spawned in.

which validates my assumption that I need to create a serviceaccount for each namespace.

Is there a work around to it perhaps ? I don't want to remember to create a service account for every new namespace we are creating.

@minrk @athornton I saw you guys worked on multiple user namespaces, which is similar idea maybe you have an idea.

Thanks

[athornton]

At my site, we do create per-namespace serviceaccounts. On my medium-term roadmap is to make a configurable way to specify K8s resources that ride along with each user pod. We use a pre-spawn hook and some additional yaml to create those resources right now.