Skip to content

[ENH] - Expose running child resources via NebariApp status.serviceDiscovery.children #117

Description

@viniciusdc

Context

The landing page wants to surface child workloads spawned by a NebariApp on a user's behalf — JHub user pods today, eventually Argo workers, LLM modules. The data plane for that already exists: the service-discovery webapi (#54) runs a controller-runtime informer cache for NebariApps and a Redis-backed Hub for multi-replica WebSocket fan-out. It is the natural place to add a Pod watcher.

For the webapi to enumerate children for a given NebariApp, child resources need a label that ties them back to their parent. Kubernetes already has a recommended one: app.kubernetes.io/part-of. The operator's job here is to make that the documented contract — not to run the watch itself.

Scope (operator)

  1. Document the convention in the NebariApp CRD docs and in the operator README:

    Resources spawned by a NebariApp pack on behalf of a user (e.g. JHub user pods) MUST carry app.kubernetes.io/part-of: <NebariApp name>. The service-discovery webapi enumerates them via this label.

  2. Software-pack Helm charts (nebari-dev/software-packs) opt in by setting that label on user-spawned resources. JupyterHub's chart already supports this via singleuser.extraLabels — confirm the pack values set app.kubernetes.io/part-of to the NebariApp name. Tracked separately in software-packs once the JHub pilot lands.

  3. (Optional, future) Add a spec.serviceDiscovery.childSelector field on the NebariApp CRD so packs can declare a non-default selector when the part-of convention doesn't fit. Defer this until a real case appears — start with a fixed convention.

Related

Metadata

Metadata

Assignees

Fields

Priority

Low

Start date

None yet

Target date

None yet

Size

None yet

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions