Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
helm install --name cds cds

Result

Code Block
$ kubectl get all --selector=release=cds
NAME                                             READY     STATUS    RESTARTS   AGE
pod/cds-blueprints-processor-54f758d69f-p98c2    0/1       Running   1          2m
pod/cds-cds-6bd674dc77-4gtdf                     1/1       Running   0          2m
pod/cds-cds-db-0                                 1/1       Running   0          2m
pod/cds-controller-blueprints-545bbf98cf-zwjfc   1/1       Running   0          2m
NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/blueprints-processor    ClusterIP   10.43.139.9     <none>        8080/TCP,9111/TCP   2m
service/cds                     NodePort    10.43.254.69    <none>        3000:30397/TCP      2m
service/cds-db                  ClusterIP   None            <none>        3306/TCP            2m
service/controller-blueprints   ClusterIP   10.43.207.152   <none>        8080/TCP            2m
NAME                                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cds-blueprints-processor    1         1         1            0           2m
deployment.apps/cds-cds                     1         1         1            1           2m
deployment.apps/cds-controller-blueprints   1         1         1            1           2m
NAME                                                   DESIRED   CURRENT   READY     AGE
replicaset.apps/cds-blueprints-processor-54f758d69f    1         1         0         2m
replicaset.apps/cds-cds-6bd674dc77                     1         1         1         2m
replicaset.apps/cds-controller-blueprints-545bbf98cf   1         1         1         2m
NAME                          DESIRED   CURRENT   AGE
statefulset.apps/cds-cds-db   1         1         2m

Design time

Bellow are the requirements to enable automation for a service within ONAP.

Currently, ONAP officially supports instantiation and post-instantiation use cases.

Instantiation use case

The goal is to be able to automatically resolve all the HEAT environment variables, called cloud parameters.

Prerequisite

  1. Have the HEAT template along with HEAT environment file
  2. Identify which cloud parameter are static and dynamic
  3. Create and fill-in the bellow table for all the dynamic cloud parameters


Cloud Parameter nameHow to resolveInput for resolutionOutput of resolution
Name as in the HEAT environment file


Deck of Cards
idhow to resolve


Card
labelInput

Value will be given as input in the request.


Card
labelDefault

Value will be defaulted in the model.


Card
labelREST

Value will be resolved by sending a query to the REST system


AuthURLURIPayloadVERB

Supported Auth type

Deck of Cards
idauth


Card
labelToken

Use token based authentication

  • token


Card
labelBasic

Use basic authentication

  • username
  • password


Card
labelSSL

Use SSL basic authentication

  • keystore type
  • truststore
  • truststore password
  • keystore
  • keystore password



http(s)://<host>:<port>/xyzJSON formatted payloadHTTP method




Card
labelSQL

Value will be resolved by sending a SQL statement to the DB system


TypeURLQueryUsernamePassword
Only maria-db supported for now


jdbc:mysql://<host>:<port>/db

SQL statement






List of all the placeholders defines in the payload, URL, URI, SQL statement, etc.This is the expected result from the system, and you should know what value out of the response is of interest for you.
In it's a JSON payload, then you should think about the json path to access to value of interest.


Required workflows

The following workflows are contracts established between SO, SDNC and CDS to cover the instantiation and the post-instantiation use cases.

...