Explore how the PodDefault for NGC container gets replicated

[NohaIhab]

What needs to get done

Define how the PodDefault (via config? via relation to resource dispatcher? charm action?) will be applied in the user namespaces

Why it needs to get done

this is one of the pieces outline the implementation for NGC container Notebook integration. It will be documented in the spec, tracked in issue https://github.com/canonical/notebook-operators/issues/326

[NohaIhab]

the PodDefault can be created via relation between jupyter-controller and resource dispatcher, it makes sense to utilize the existing resource-dispatcher charm. It will be done similarly to the relation between mlflow-operator and resource-dispatcher charms.

Charm implementation

resource-dispatcher charm

• requires a pod-defaults interface -> this is already implemented
• applies the PodDefault from the relation to the user namespaces

jupyter-controller charm

• provides a pod-defaults interface, it will be like:

  provides:
  pod-defaults:
  interface: pod-defaults
  schema:
    v1:
      provides:
        type: object
        properties:
          pod-defaults:
            type: string
      required:
      - pod-defaults
  versions: [v1]

• owns the definition of the PodDefault suggested in #325 as a yaml under src/templates
• implements an event handler for on.relation_changed (possibly in the main handler) to send the PodDefault to the relation interface

User experience

The user will need to:

• add the relation explained above with juju relate
• when creating a notebook with the NGC image, select the configuration (the PodDefault) from the dropdown list The steps will be documented in a how-to guide The PodDefault's desc field should make it very clear that it is for NGC containers only when the notebook image is an NGC one.

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5143.

This message was autogenerated

[NohaIhab]

the name of the integration in resource-dispatcher and jupyter-controller can be different (see juju docs), so we should make the integration name in jupyter-controller charm's side unique to NGC, while keeping the interface the same. It can be something like ngc-command. This is useful if we want to add other poddefaults for different containers.

[kimwnasptd]

Closing this since we discussed all the above with @NohaIhab and this is our plan for the implementation

[NohaIhab]

In the end after some discussions, we're going with a different implementation. A new charm ngc-integrator will own the poddefault and send it to resource dispatcher. This way, we are encapsulating the ngc configurations in an integrator charm. For more details, see the spec.