Check out CodeCatalyst as an alternative/supplement to VSCode Devcontainer

• https://github.com/mbtamuli/csi-quickstart/blob/add_aws_devenvironment/.codecatalyst/devfile.yaml
• https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html

Goals

• Create separate GitHub Actions workflow to
  • Build the plugin and Docker image
  • Test the plugin against a cluster running in the pipeline
  • Publish the Docker image to GitHub Container Registry

Approach

• After #12 is done, this will be pretty straightforward as the workflows can just invoke the scripts.

Goals

• Implement logging for the plugin
  • Use structured logging
  • Implement gRPC logging to log request/response in debug level
• Update Decisions and any relevant documentation

Goals

• Implement code for these methods in the service interfaces
  • CSI Identity Service
    • #24
  • CSI Node service
    • #25
    • #26
• Verify whether these methods are needed and implement if necessary
  • CSI Identity Service
    • GetPluginCapabilities method
    • Probe method
• Update documentation if required

Update

These are not mandatory.

• GetPluginCapabilities method
• Probe method

Goals

• Add test to successfully create a Pod using emptyDirClone volume
• Add test to successfully read and write, to a path within the volume, from a single container in a Pod
• Add test to successfully read and write, to a path within the volume, from a multiple containers in a Pod
• Document steps to run all or selection of tests

Approach

• Check out https://github.com/kubernetes-sigs/e2e-framework

Related to #11

• After adding tests, write empty methods to check tests failing
• After setting up the workflow with tests and empty methods added, continue with action implementation

Goals

• Scripts to setup and teardown a local Kubernetes cluster
• Document steps and any pre-requisites

Stretch Goals

• #15

Goals

• Implement Setup skeleton code for these methods in the service interfaces
  • CSI Identity Service
    • GetPluginInfo method
    • GetPluginCapabilities method
    • Probe method
  • CSI Node service
    • NodePublishVolume method
    • NodeUnpublishVolume method
• Update documentation with steps to build and run manually

Approach

• Setup skeleton of the CSI plugin
• Add empty methods and deploy to check failing tests. Refer #10 and #12
• Go thoroughly through the Required Reading section
• Use csc to test any implemented method before trying to deploy on cluster

Manual testing steps

1. Running locally > Build and Deploy
2. Running tests

Goal

• Find out what is the official/conventional way to create the volumes
  • same volume as CSI
  • separate volume

Background

Ref: #25 (comment)

• A volume mounted from the host in both the plugin container and the node-driver-registrar container, which is used primarily for the CSI socket

  spec:
    template:
      spec:
        containers:
          - volumeMounts:
              - mountPath: /csi
                name: plugin-dir
        volumes:
          - hostPath:
              path: /var/lib/kubelet/plugins/emptydirclone.mriyam.dev
              type: DirectoryOrCreate
            name: plugin-dir

• The plugin creating a volume, that gets mounted at the target path as requested by kubelet. Now the path that the plugin uses for creating the volume lives under the path /csi

   // getVolumePath returns the canonical path for emptydirclone volume
   func getVolumePath(volName string) string {
   	return filepath.Join("/csi/data", volName)
   }

Although this works, the pattern I've seen is,

• A volume separate from the one used for the CSI socket mounted from the host in both the plugin container and the node-driver-registrar container

  spec:
    template:
      spec:
        containers:
          - volumeMounts:
            - mountPath: /csi-data-dir
              name: csi-data-dir
      volumes:
        - hostPath:
            path: /var/lib/csi-emptydirclone.mriyam.dev-data/
            type: DirectoryOrCreate
          name: csi-data-dir

• The plugin uses the volume /csi-data-dir/ to create all volumes within that path.

Goal

• Should the basic CSI plugin emulate emptyDir or hostPath volume. - Update ./README.md with decision and reasoning. - #5
• Clear requirements for a <TBD type> CSI plugin simulating emptyDir. - #6
• Any additional diagram or commentary explaining unclear parts of Specification. - #6

Approach

• Reading material
  • https://kubernetes-csi.github.io/docs/
  • https://github.com/kubernetes-csi/csi-driver-host-path
  • https://github.com/rexray/gocsi/tree/master/csc
  • https://arslan.io/2018/06/21/how-to-write-a-container-storage-interface-csi-plugin/

Testing of creation of issue via quick link provided by GitHub. Can be ignored.

Goals

• Have scripts to easily build, run(#11) and test(#10) the plugin in the local cluster(#9)
• Update documentation

Add a README defining the goal/scope of the project

Reading

• https://github.com/container-storage-interface/spec/blob/master/spec.md#nodepublishvolume
• https://github.com/kubernetes/design-proposals-archive/blob/main/storage/container-storage-interface.md#mounting-volumes
• https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
• https://github.com/kubernetes-csi/csi-driver-host-path/blob/c28be1924239fc8d08ee4b6ffec457237d4bd26f/pkg/hostpath/nodeserver.go#L40

Scope

• #9
• #10
• #11
• #12
• #13

Additions

• #23
• #22 (ref: #11)

Reading

• https://github.com/container-storage-interface/spec/blob/master/spec.md#nodeunpublishvolume
• https://github.com/kubernetes/design-proposals-archive/blob/main/storage/container-storage-interface.md#mounting-volumes
• https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
• https://github.com/kubernetes-csi/csi-driver-host-path/blob/c28be1924239fc8d08ee4b6ffec457237d4bd26f/pkg/hostpath/nodeserver.go#L208

Reading

• https://github.com/container-storage-interface/spec/blob/master/spec.md#identity-service-rpc
• https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo