Draft for OCL 2.0

[iskey]

OCL 2.0

# The version of the OCL
version: 2.0
# The Service provided by the ISV, the name will be shown on the console as a service.
name: kafka
# The version of the service, if the end-user want to select the version when they want to deploy the service.
service_version: v1.0
# For the users may have more than one service, the @namespace can be used to separate the clusters.
description: This is an ehanced kafka services by ISV-A.
namespace: ISV-A
# Icon for the service.
icon: |
  data:image/svg+xml;base64,PCEtLQogIC0gU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEFwYWNoZS0yLjAKICAtIFN
  QRFgtRmlsZUNvcHlyaWdodFRleHQ6IEh1YXdlaSBJbmMuCiAgLQogIC0tPgoKPHN2ZyB3aWR0aD0iMjAwIiBoZWlnaHQ9
  IjIwMCIgdmlld0JveD0iMCAwIDIwMCAyMDAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI
# Reserved for CSP, aws,azure,ali,huawei and ...
cloud_service_provider:
  name: huawei
  regions:
    - cn-north-4
    - cn-southwest-2
billing:
  - # The business model(`flat`, `exponential`, ...)
    model: flat
    # The rental period (`daily`, `weekly`, `monthly`, `yearly`)
    period: monthly
    # The billing currency (`euro`, `usd`, ...)
    currency: euro
# The flavor of the service, the @name/@version/@flavor can locate the specific service to be deployed.
flavors:
  - name: 3-node-without-zookeeper
    # The fixed price during the period (the price applied one shot whatever is the service use)
    fixedPrice: 20
    # Properties for the service, which can be used by the deployment.
    property:
      node: 3
      zookeeper: false
  - name: 5-node-with-zookeeper
    # The fixed price during the period (the price applied one shot whatever is the service use)
    fixedPrice: 30
    # Properties for the service, which can be used by the deployment.
    property:
      node: 5
      zookeeper: true
deployment:
  # Context for deployment: the context including some kind of parameters for the deployment, such as fix,variable.
  # - fix: The value of the fix parameters are defined by the ISV with the @value at the initial time.
  # - variable: The value of the variable parameters are defined by the user on the console.
  # The parameters will be used to generate the API of the managed service.
  context:
    - name: AK
      description: Your access key.
      kind: fix
      type: string
      value: xxxxxxxxxx
      madatory: true
      validator: null
    - name: SK
      description: Your security key.
      kind: fix
      type: string
      value: xxxxxxxxxxx
      madatory: true
      validator: null
    - name: VPC
      description: The vpc you want to deploy, If null, A new vpc will be created.
      kind: variable
      type: string
      madatory: false
      validator: @length(1-256)
  # Deployer: Supported values are terraform, plulumi, crossplane.
  deployer:
    terraform: |
      variable "secgroup_id" {}

      data "huaweicloud_availability_zones" "myaz" {}

      data "huaweicloud_compute_flavors" "myflavor" {
        availability_zone = data.huaweicloud_availability_zones.myaz.names[0]
        performance_type  = "normal"
        cpu_core_count    = 2
        memory_size       = 4
      }

        data "huaweicloud_vpc_subnet" "mynet" {
        name = "subnet-default"
      }

        data "huaweicloud_images_image" "myimage" {
        name        = "Ubuntu 18.04 server 64bit"
        most_recent = true
      }

        resource "huaweicloud_compute_instance" "basic" {
        name               = "basic"
        image_id           = data.huaweicloud_images_image.myimage.id
        flavor_id          = data.huaweicloud_compute_flavors.myflavor.ids[0]
        security_group_ids = [var.secgroup_id]
        availability_zone  = data.huaweicloud_availability_zones.myaz.names[0]

        network {
        uuid = data.huaweicloud_vpc_subnet.mynet.id
      }
      }

A simple diagram for this.

[swaroopar]

In general the idea is good and matches to what we would like to do.
I can think of the following points for now -

1. Flavors should be a list.
2. terraform scripts should be flavors dependent.
3. Instead of passing terraform script as it is.. is it possible to send it also as json or yaml -> https://developer.hashicorp.com/terraform/language/syntax/json

[niuzhenguo]

it's ok to use json with terraform, but HCL is more common.

[iskey]

1. We can make flavors to be a list. Let's have a try.
2. My original idea is to make the OCL a one-flavor descriptor. But we also can try to make a relation between the flavors and the scripts in another way, something like variables for the scripts.
3. I think we should keep the deployment part of the OCL opening and extendable, so we would make the users be able to choose any popular IAC techs someday.

[swaroopar]

it's ok to use json with terraform, but HCL is more common.

Agree completely. was only thinking more about parsing it or catching errors. If it makes sense to use HCL as it is inside a yaml or json, then lets go for it.

[niuzhenguo]

Regarding the terraform scripts, maybe better also to support using existing scripts on github or terraform registry modules like:

source = "huaweicloud/kafka"

[iskey]

That's great~

[niuzhenguo]

We may need to think about of adding some restrictions to the terraform scripts/modules, like need to provide a variables.tf defination corresponding to the flavor properties as input to terraform and also something like this for terraform output which maybe useful for monitoring or others.

[iskey]

A simple diagram for the draft.

[swaroopar]

@iskey Please also consider adding an "icon" (image to be displayed) field to the OCL. Should be enough for now to send it is base64 encoded field.

[iskey]

@iskey Please also consider added an "icon" (image to be displayed) field to the OCL. Should be enough for now to send it is base64 encoded field.

Good idea. Added like this: Icon