feat(crd): AmaltheaSession definition

[sgaist]

Describe your changes

This PR implements the new AmaltheaSession CRD.

The goal of the this new session is to give user the option to use other development environments than just JupyterLab.

New Docker images as well as instructions will be created as well as part of the implementation.

Issue ticket number and link

Part of SwissDataScienceCenter/renku#3679

[olevski]

Thank you for starting this Samuel. This is a great starting point.

A few things we will have to add in subsequent PRs:

• port on which the session will run
• information about ingress (i.e. tls secret and host name)

[olevski]

Suggested change

	secret:
	type: string
	description: Name of the secret containing the credentials for the
	secret:
	type: string
	description: Name of the Kubernetes secret located in the same namespace as the session, containing the TOML Rclone configuration for the remote that stores the data to be mounted. The `remote` field above should match the `remote` name in the Rclone configuration. Please note that the secret containing this configuration will be "adopted" as a child resource of the session and therefore will be deleted when the session is deleted.

[rokroskar]

is this necessarily rclone-specific? If so we should clearly specify somewhere that dataSources are only meant to work with the rclone-csi driver

[olevski]

I am not sure how else we can generalize this. If we have no constraints on this secret at all it becomes unusable.

[olevski]

The alternative is to ask for a list of pvc names and paths where they should be mounted in the session. Then we do not have to ask for a secret and it is the job of the user of amalthea to create the PVCs whichever way they see fit.

[sgaist]

Since a data source might be different things, what about having an rclone object a bit like the git object from the repositories above ?

That way, it makes it easier to add support for other data sources.

[olevski]

@sgaist this makes sense. I will add this when I convert the CRD spec to the go framework we will use. You dont have to add it now just so we change it later.

[rokroskar]

Thanks @sgaist for kicking this off! Just a few minor suggestions from my side.

[rokroskar]

is this necessarily rclone-specific? If so we should clearly specify somewhere that dataSources are only meant to work with the rclone-csi driver

[sgaist]

Sorry guys, I just realized that I rebased on top of main out of habit and forgot that it nukes GitHub's conversations.

[Panaetius]

do we need a targetNamespace parameter? Current sessions can be scheduled in a namespace other than where amalthea runs.
Also for the cross cluster stuff we're investigating a targetCluster but that can be added later.

[sgaist]

do we need a targetNamespace parameter? Current sessions can be scheduled in a namespace other than where amalthea runs. Also for the cross cluster stuff we're investigating a targetCluster but that can be added later.

I haven't followed the cross cluster design/implementation but I would say yes, let's keep that for later as it will be highly dependent on how the inter-cluster communication/sync is implemented.

Changes have been addressed