IBM Cloud Satellite storage

This repository is used to develop storage templates to install your vendor storage solution in clusters that run in IBM Cloud Satellite. As a vendor, you can create and test your storage templates by following this README. After your template is approved, it can be deployed to clusters that run in IBM Cloud Satellite.

Overview

With IBM Cloud Satellite, you can bring your own compute infrastructure that is in your on-premises data center, at other cloud providers, or in edge networks as a Satellite Location to IBM Cloud. Then, you use the capabilities of Satellite to run IBM Cloud services on this infrastructure, and consistently deploy, manage, and control your app workloads. For more information, see the IBM documentation.

• IBM Cloud Satellite
• Getting started

Satellite storage partner certification process

Registering with IBM Cloud

1. Create an IBMid.

2. Email contsto2@in.ibm.com.

   1. Include the subject line: IBM Cloud Satellite Storage <storage-solution-name> Integration*. For example: IBM Cloud Satellite Storage LocalVolume Integration.
   2. Provide a high level description of the storage solution with a link to the user documentation or public repository.

3. Complete the onboarding process

4. Complete the Certification Requirements checklist.

Creating and testing your deployment

1. Create a deployment.yaml file to deploy Kubernetes resources for the storage operator or driver in the development enviornment. Review the following example deployment.yaml to deploy the local-volume operator.

   apiVersion: v1
   kind: List
   metadata:
       name: local-storage
       namespace: kube-system
       annotations:
           version: local-storage-45
   items:
     - apiVersion: v1 [1]
       kind: Namespace
       metadata:
           name: local-storage
     - apiVersion: operators.coreos.com/v1alpha2 [2]
       kind: OperatorGroup
       metadata:
           name: local-operator-group
           namespace: local-storage
       spec:
           targetNamespaces:
             - local-storage
     - apiVersion: operators.coreos.com/v1alpha1 [3]
       kind: Subscription
       metadata:
           name: local-storage-operator
           namespace: local-storage
       spec:
           channel: "4.5"
           installPlanApproval: Automatic
           name: local-storage-operator
           source: redhat-operators
           sourceNamespace: openshift-marketplace
     - apiVersion: local.storage.openshift.io/v1 [4]
       kind: LocalVolume
       metadata:
          name: local-disk
          namespace: local-storage
       spec:
           nodeSelector:
               nodeSelectorTerms:
                  - matchExpressions:
                        - key: storage
                          operator: In
                          values:
                              - "localvol"
           storageClassDevices:
               - storageClassName: "localblock-sc"
                 volumeMode: Block
                 devicePaths:
                    - /dev/xvde

2. Once you get your development environment, test your deployment.

   1. From IBM Cloud Console -> Satellite -> Configurations -> Create Configuration
   2. From IBM Cloud Console -> Satellite -> Configurations -> Select the Configuration -> Add version and upload the deployment yaml
   3. From the IBM Cloud Console -> Satellite -> Configurations -> Select the Configuration -> Create Subscription
   4. Verify that the resources are deployment to the cluster.
   5. Create a PVC and run the sniff test using the IBM Provides test bucket to make sure deployment is working as expected.

3. After you have verified your template in the development environment, create an issue in this repo.. Review the formatting of the example issue. Include the following information in your issue and ensure that you remove any secrets from your files.

   1. Your deployment.yaml file.
   2. An examplepvc.yaml file.
   3. An example app.yaml.
   4. The output of the oc get sc command that displays the storage classes your deployment creates.
   5. The output of the oc get -n <namespace> pvc command that displays the PVCs your deployment creates.
   6. The output of the oc get -n <namespace> pods command that displays the pods your deployment creates.

Developing your Satellite storage configuration template

1. Fork this repository.

2. Convert the deployment.yaml to a Satellite storage template. In your fork, make sure that you create your directory structure in the following format. For more information about the template files, review the reference table.

   config-templates
   ---<storage-provider-name> 
      ---<storage-offering-name>
         ---<template-version>
               ---deployment.yaml
               ---custom-parameters.json
               ---storage-class-template.yaml
               ---storage-class-parameters.json
               ---metadata.json
               ---README.md

File reference

| storage-provider-name | The name of storage provider. Example: ibm, aws, azure, netapp, dell. | | storage-offering-name | The storage offerig name. A provider can have multiple storage offerings for IBM satallite. | | template-version | The template version. There can be multiple tempalte version for a storage offering | | deployment.yaml | A custom Kubernetes List that includes the resources like Deployment, StatefulSet, DaemonSet, Configmap, secrets, and storage classes. Example deployment.yaml. | | custom-parameters.json | This file contains the list of parameters that your deployment accepts. Include any required and optional paramters and their default values. Example customer-paramerters.json. | | storage-class-template.yaml | The storage class template. This template can be used to create storage classes on a Satellite cluster. Example storage-class-template.yaml. | | storage-class-parameters.json | The list of storage class parameters. User / admin can override the values from GUI. The parameter values are injected in storage class template to generate the storage class specifications to deploy on the target clusters. storage-class-parameters.json | | README.md | Contains prerequisites, deployment steps, and additional information about your template. Copy and fill out the README_TEMPLATE.md. | | metadata.json | This file contains the metadata for GUI display. Example metadata.json. |

Setting dynamic parameters in your deployment

In this example, the devicepath parameter is set dynamically. In a local storage configuration, the device path of the local disks might vary from one cluster to another. To account for this in your configuration template, you can create a dynamic parameter.

1. Parameterize the device path in the template deployment.yaml file in the following format. The parameter name devicepath is passed in the format: "{{ <parameter-name> }}"

      storageClassDevices:
         - storageClassName: "localblock-sc"
            volumeMode: Block
            devicePaths:
               - "{{ devicepath }}"

2. Add the parameter to your custom-parameters.json file in the following format. You can also include a default value for the parameter.

      {
      "description": "A description of the parameter.",
      "displayname": "The display name for the Satellite UI",
      "name": "devicepath",
      "default": "/dev/sdc",
      "required": true,
      "type": "text"
      }

Custom parameter reference

| description | A description of the parameter. | | displayname | The display name of the parameter that is used in the Satellite UI. | | name | The name of the parameter in string format. | | default | Optional. The default value for the parameter. If the does not specify the parameter in their configuration, this value entered as default is used. | | required | Specify true or false. | | type | Specify the parameter type. Valid parameter types are: text, secret, boolean, option, or dropdown. |

Testing and support

1. Create a configuration from a template in your fork. When you run the sat storage config create command, specify the source-org and source-branch of your fork and any other parameters for your configuration.

   ibmcloud sat storage config create --name <config-name> --template-name <template-name> --template-version <template-version> --source-org <your-github-org> --source-branch <your-github-branch> [-p "<parameter>=<value>" -p "<parameter>=<value>"]

2. Assign your configuration to a cluster.

   ibmcloud sat storage assignment create --name <assignment-name> --group <cluster-group> --configuration <config-name>

3. Develop test cases for verification testing. You test case should include the following:

   • Steps to set up the environment or deploy any prerequisites.
   • Test to verify the functionality of the Storage driver.

4. Provide a runbook for customer support. Include the following information in your support runbook.

   • Support contact details.
   • Link to support site or support ticket process.
   • Steps to collect data for debugging.
   • Known issues and steps to resolve the issue.

Requesting review

After you have completed testing, you can open a PR to request a review from the Satellite storage team.

1. Create a PR from your fork to the develop branch of this repo.

2. The Satellite storage team will review your PR and request changes or approve.