Skip to content

Latest commit

 

History

History
215 lines (179 loc) · 11.9 KB

README.md

File metadata and controls

215 lines (179 loc) · 11.9 KB
Raw

IBM Cloud Satellite storage

IBM Cloud Satellite Storage provides capabilities to manage the lifecycle of a storage solution on a ROKS cluster deployed in a Satellite Location. It simplifies the storage solution deployment and maintenance including security patches & version upgrades. The core objective is to simplify the storage life cycle management for Cluster Admins by hiding the complexity.

This repository is to collaborate with IBM Partners and Storage Solution Vendors to develop storage configuration templates for 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.

Satellite storage partner certification process

Storage Template Registration Flow

Registering with IBM Cloud

  1. Create an IBMid.

  2. Create an issue under IBM Satellite Storage repo.

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

Setting up your development environment

  1. Collaborate with the IBM Cloud Satellite Storage Team to setup your Satellite Location for development and testing.

Testing your storage solution in IBM Cloud Satellite

  1. Create a deployment.yaml file to deploy Kubernetes resources for the storage operator or driver in the development environment. 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. 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, update the 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.

Validating and certifying your solution

The IBM storage team will collaborate with you to ensure your product works well with the IBM Cloud Paks. The intent of this certification is for our two companies to produce enterprise grade, best of breed, resilient, scalable solutions driving toward a consistent and maintainable deployed environment.

  1. Review and complete the certification requirements

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

File name Description
storage-provider-name The name of storage provider. Example: ibm, aws, azure, netapp, dell.
storage-offering-name The storage offering 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",
      "regex": "^/dev/[a-zA-Z0-9]+$",
      "max-length": "64",
      "required": "true",
      "category": "config",
      "obfuscate": "false",
      "type": "text"
   }

Understanding the Satellite storage template parameters

Parameter name Description
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.
regex Regular expression to validate the parameter value.
max-length Maximum length of the parameter value.
required Specify false if the parameter is optional otherwise false.
category Specify secret if the parameter is a secret otherwise config.
obfuscate Set it to true if you want to hide the value in GUI or CLI output.
type Specify the parameter type. Valid parameter types are: text, boolean, or cvs.

Testing and support

  1. Once you are ready with your storage configuration template, raise a PR for https://github.com/IBM/ibm-satellite-storage

  2. IBM Cloud Satellite Storage Team will review the PR and provides you the required access to your storage configuration template.

  3. Get the list of supported templates

    ibmcloud sat storage template ls

  4. Review your template

    ibmcloud sat storage template get --name <template-name> --version <template-version>

  5. Create a configuration using your template. Provide the required parameters as per your template.

    ibmcloud sat storage config create --name <config-name> --location <location-id> --template-name <template-name> --template-version <template-version>  [-p "<parameter>=<value>" -p "<parameter>=<value>"]

  6. Assign your configuration to the cluster.

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

  7. Develop test-cases for verification testing. The 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.

  8. 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.