Table of Contents
outline true

Introduction

...

ONAP services need to be registered to MSB to leverage the service discovery/routing/LB capabilities of MSB. The below table is the information MSB need for service registration.

See also the complementary set official reference list of externally exposed ports for OOM at OOM NodePort List - until most of the ports are generated dynamically

...

• The collected service endpoint information will be added to OOM deployment blueprint, which is kubernetes configuration file in Amsterdam release.

• OOM deploy MSB as the first component 

• OOM deploy Registrator, which watches the kubernetes POD events

• OOM deploy other ONAP components,like AAI, Poliy, SO,VFC, APPC, etc.

• Registrator get notified with the POD event, then get the service information form POD environment variables and service instance(POD) IP from kubernetes

• Registrator registers the service endpoint info to MSB

• MSB use these service info to route service requests

Image Removed

• , Poliy, SO,VFC, APPC, etc.

• Registrator get notified with the POD event, then get the service information form POD environment variables and service instance(POD) IP from kubernetes

• Registrator registers the service endpoint info to MSB

• MSB use these service info to route service requests

Image Added

Service information to be registered to MSB can be added as an annotation "msb.onap.org/service-info" to K8s service spec YAML.

Example：

https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob_plain;f=kubernetes/multicloud/templates/service.yaml;hb=refs/heads/master

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.service.portName }}
  namespace: {{ include "common.namespace" . }}
  labels:
    app: {{ include "common.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ include "common.release" . }}
    heritage: {{ .Release.Service }}
  annotations:
    msb.onap.org/service-info: '[
    {
      "serviceName": "multicloud",
      "version": "v0",
      "url": "/api/multicloud/v0",
      "protocol": "REST",
      "port": "{{ .Values.service.externalPort }}",
      "enable_ssl": {{ .Values.config.ssl_enabled }},
      "visualRange": "1"
    },
    {
      "serviceName": "multicloud",
      "version": "v1",
      "url": "/api/multicloud/v1",
      "protocol": "REST",
      "port": "{{ .Values.service.externalPort }}",
      "enable_ssl": {{ .Values.config.ssl_enabled }},
      "visualRange": "1"
    }
    ]'
spec:
  ports:
  {{if eq .Values.service.type "NodePort" -}}
  - port: {{ .Values.service.externalPort }}
    nodePort: {{ .Values.global.nodePortPrefix | default .Values.nodePortPrefix }}{{ .Values.service.nodePort }}
    name: {{ .Values.service.portName }}
  {{- else -}}
  - port: {{ .Values.service.externalPort }}
    targetPort: {{ .Values.service.internalPort }}
    name: {{ .Values.service.portName }}
  {{- end}}
  selector:
    app: {{ include "common.name" . }}
    release: {{ include "common.release" . }}
  type: {{ .Values.service.type }}

Backwards compatible

While trying to provide consistent RESTful APIs to ONAP developers and users, some projects may also want to support their current API version until an appropriate time to deprecate it. In case of that, two service endpoints can be defined for a service, one for the consistent, standard way and one for backwards compatible.

The customized publish path of this service attribute can be used to support the current API. If this parameter is specified when registering the service, the service will be published to api gateway under the specified customer path other than the the fixed format: api/{serviceName} /{version}.

for example, A&AI defines two services for its Cloud Infrastructure API,  the "aai-cloudInfrastructure" is published under /api/aai-cloudInfrastructure/v1/ which is the consistent, standard API URL, and the "aai-cloudInfrastructure-deprecated" is published under /cloud-infrastructure/ which is the same as its current API URL.

...

...

...

Usecase UI

...