eclipse-xpanse / xpanse Goto Github PK

Using services could be confusing (it's actually runtime services).

I will rename services as modules and move actual orchestrator plugins into a plugins submodule.

The purpose is really to describe Kafka managed service using OCL and use it as development base for Orchestrator plugins.

Bring SLF4J as the default logging framework for OSC

Especially for the tests, I will add k8s Deployment and Service yaml file to easily deploy OSC on a K8S cluster.
I will also provide helm package to simplify "remote" deployment.

As no all platform has docker, we should disable docker build by default and build only on demand (using docker.build property for instance).

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

The purpose is to package the demo as docker image and provide k8s claim files (yaml) or helm charts.

Close to RC1, as soon as we have the required resources, we should test deployment of service on HuaweiCloud.
For that, we need:

• runtime
• orchestrator
• HuaweiCloud plugin

I want to make OrchestratorStorage a service. So we can get the OrchestratorStorage from the registry at a convenience.

with local packer cmd impl.

Add a RuntimeBase class as the basic of runtime meta.

Currently, GH action doesn't work (expected as the Minho SNAPSHOTs are not yet available on Apache repository). When artifacts will be available, I will double check that GH action build is OK (CI/CD).

Close to RC1, as soon as we have the required resources, we should test deployment of service on openstack/OTC.
For that, we need:

• runtime
• orchestrator
• openstack plugin

Especially for test locally on minikube, I propose to create a kubernetes plugin with the following behqvior:

1. Create a pod per resource deployment (pod lifetime is the resource provisioning), using fabric8 kuberenetes client
2. Check resources via kubernetes API

I propose adding a plugin-level storage API.
For we need somewhere to store the plugin-level information.

Add OBS impl for orchestrator storage in HuaweiCloud plugin

OBS sdk: https://github.com/huaweicloud/huaweicloud-sdk-java-obs

Task List

• Translate image block to Packer description.
• Translate vm block to Terraform description.
• Translate network block to Terraform description.
• Translate storage block to Terraform description.

kanban action testing

I will double check the pom.xml I created to verify if:

• release plugin configuration is OK
• all is set to upload artifacts on Maven Central (or another Maven public repository)

Export a new API for the status and properties of the managed infra.

Right now the orchestrator is just delegating any OCL descriptor to all registered plugins.

We can imagine to have a filter based on OCL properties to define this OCL should be managed by these plugins.
The ConfigService can contain a property containing mapping of orchestration plugin / ocl name.

Hi, team

I found that Yichao is using IntelliJ and I am using VSCode, so the coding style/formatter by IDE is a bit different. Shall we use Google Java Style (https://google.github.io/styleguide/javaguide.html) and a maven plugins to format code in every build ?

I propose to create an OSC runtime distribution per CSP/plugin:

• osc-hc (for huawei cloud)
• osc-openstack
• osc-k8s

To create resources in the orchestrator plugin, we need authentication information.
I propose to add authentication list at OCL level. It will like:

  "authentication": [
     {
         "id": "main_auth",
         "url": "https://identity.api.my.cloud:443/v3/auth/tokens",
         "properties": {
             "tenant": "${env:tenant}",
             "username": "${secret:username}",
             "password": "${secret:password}"
          }
  ]

Thoughts ?

I have submitted Apache Karaf Minho 0.1 release to vote this morning. I will update to this version in OSC (instead of using SNAPSHOT).