Grouping the labels enables us to query for all pods from components that might be a part of the CSI driver.

For e.g.

kubectl logs --follow $(kubectl get pods -l 'app.kubernetes.io/name=csi-hostpathplugin' --all-namespaces -o jsonpath='{.items[*].metadata.name}')

Basically update the chart/deployments to componentized labels.

  labels:
    app.kubernetes.io/instance: csi.oras.land 
    app.kubernetes.io/part-of: csi-driver-oras
    app.kubernetes.io/name: csi.oras.land
    app.kubernetes.io/component: oras-csi-driver

See - main...sajayantony:oras-csi:labels#diff-a8700dba16974edcf2b009ae853444d94109db94d7538ea2038d72ae2966f68b

Basic level of acceptability for new project

• writeup of use cases we are interested in addressing #7
• an ability to specify conditions for cleaning up an artifact when the kubernetes pod / object is deleted
• Some testing of the CSI I didn't add the sanity-test (want to better understand this) but I added and end to end test for creating a v pod.
• helm chart

Larger goals

• standards for defining assets and actions to take (e.g., copy this binary here, this directory here, get this annotation and do X, name this file Y)
• an ability to specify and enforce some permissions namespace for the artifacts (e.g., for multi-tenant cluster)
  • enforceNamespace option for driver
• Allow predictable naming for an artifact
• More proper docs / branding
  • convert README into docs folder #7

The pv datapath currently has : if there is a port or a digest form. Good news is that deployments from digest tags works. :)

I don't know if this is an issue but most likely need to consider if we should sanitize this further.

Preparing to pull from remote repository: kind-registry:5000/java-app"
Plain http: true"
Found digest: sha256:4fe6f3e48881647c22bea5c5ca02872b6f5d9ff75931a692e00c50f59de3f429 for sha256:4fe6f3e48881647c22bea5c5ca02872b6f5d9ff75931a692e00c50f59de3f429"
Pulling sha256:514fd93c4f9d875fc5c98532f2399a740d4e02a8eefe4a71155e8d92c69e14fb, 0 of 1"
OCI: Writing sha256:514fd93c4f9d875fc5c98532f2399a740d4e02a8eefe4a71155e8d92c69e14fb to /pv_data/default/kind-registry:5000-java-app-sha256:4fe6f3e48881647c22bea5c5ca02872b6f5d9ff75931a692e00c50f59de3f429/HelloWorldServer.jar"
Oras artifact root: /pv_data/default/kind-registry:5000-java-app-sha256:4fe6f3e48881647c22bea5c5ca02872b6f5d9ff75931a692e00c50f59de3f429"

If this isn't important let's close the issue.

This restriction should only be enforced upon manifest/index, not the sif container blob.

Can I just unset this limit

yes, it's an option which you can change in the resolve option

https://github.com/oras-project/oras-go/blob/e8225cb1e125bd4c13d6b586ae6d862050c3fae2/content.go#L58u

It might be the case that we want an artifact to be cleaned up after the fact, or I can see some kind of cleanup logic implemented on the level of the driver itself. Thus, we should brainstorm an ability to specify conditions for cleaning up an artifact when the kubernetes pod / object is deleted, both on the level of the pod and the driver itself.

I'm not actually sure this will work given the need to make binds - my early tests produced weird bugs, and I didn't want to have to distinguish them resulting from an issue with the driver vs. using kind so I stepped back and decided to come back to this later.

This might be another project, but arguably I should be able to selectively pick blobs from an ORAS artifact, and then specify where I want them in my container. E.g.,:

• take the aws-cli binary and put in /usr/local/bin
• move this entire config directory here
• get the annotation XYZ and turn it into a file here

Since these actions need to happen inside the container, we likely can't rely on making many mounts, but rather there could be a binary that is injected into the container by the driver, and then the binary takes a manifest of instructions (akin to the above) and a path to the mounted directory, and does the operations for the mount.