Document OSC controller proposal for RC2

[jbonofre]

Currently, OSC RC1 looks like a Java based "terraform": we have a OCL descriptor directly creating the end user resources.

So basically, if we consider Apache Kafka, right now, OSC directly created kafka cluster with OCL descriptor.

However, it's not the target objective of OSC: OSC is more a MSP (Managed Services Provider) framework. OSC should deploy a "controller". This controller is what we can see in CSP console, and the end user will use this controller to actually create the resources. For instance, in case of Kafka, the controller will be use by the end users (via API or via console) to actually create kafka cluster/brokers.

So, OSC should be a "controller provisioner", with:

• OCL describing the controller bootstrap/provisioning
• OCL should contain all controller configuration to allow the controller to manage resources on user requests

@Jiajia-Wen @iskey @niuzhenguo

[Jiajia-Wen]

If we treat OSC as a "controller provisioner", the idea is more like to enable "operator" in K8S ecosystem while the "K8S ecosystem“ here is different Cloud (e.g. AWS, Huawei Cloud). The challenge in the"operator" model are 1) Operator is just another container/deployment in K8S, so what is the difference between "controller provisioner" and "data plane provisioner" e.g. provision a Kafka cluster in user's VPC. 2) a controller need to communicate with data plane to know the data plane status (e.g. metrics) and adjust data plane (e.g. change config , add more nodes). Do we want to cover this aspect in OSC?

[jbonofre]

@swaroopar just about what we discussed this morning

[jbonofre]

I started a discussion about that: https://github.com/huaweicloud/osc/discussions/108

[iskey]

I think this is out of date.