Tracking of designs of functionality and API

1, F-GPS:

Please refer to the patch https://gerrit.onap.org/r/#/c/78634/ which elaborate how to enhance current API to support F-GPS.

The AZ names should be discovered by multicloud discovery/registry process, the AAI schema can be reused without change:

https://nexus.onap.org/service/local/repositories/releases/archive/org/onap/aai/aai-common/aai-schema/1.3.3/aai-schema-1.3.3.jar/!/onap/aai_swagger_html/aai_swagger_v14.html#operation--cloud-infrastructure-cloud-regions-cloud-region--cloud-owner---cloud-region-id--availability-zones-availability-zone--availability-zone-name--get

2, SO/MC integration

Create Workload: https://wiki.onap.org/display/DW/SO+to+Multicloud+API+enhancements

AAI updating: https://wiki.onap.org/pages/viewpage.action?pageId=58228881

SDC design: https://gerrit.onap.org/r/#/c/75851/

3, FCAPS enhancement

MULTICLOUD-523 - Getting issue details... STATUS

https://wiki.onap.org/download/attachments/53249985/FCAPS%20enhancement%20plan.pptx?version=1&modificationDate=1548905759000&api=v2

4, Multi-Tenant Support

MULTICLOUD-527 - Getting issue details... STATUS

https://gerrit.onap.org/r/#/c/82085/

So far MultiCloud exposed API with ID of a cloud region, assuming the consumer will issue the API request with the default tenant which are part of the AAI cloud region. With that the different tenants on the same VIM/Cloud instance can only be on-boarded into ONAP as different cloud regions.

To support the vision of enabling multiple tenants on the same cloud region, multicloud could help from following aspects:

a, discover all tenants from the VIM/Cloud instance and register them under one AAI cloud region, this is already done if the tenant user comes along with privilege to get list of tenants of the VIM/Cloud instance.

b, MultiCloud NBI should allow consumers to specify the tenant name/id during the requesting the API to MultiCloud. This can be done on various way, the easy and backward compatible approach is to having consumers putting the tenant ID/name into the "optional" request headers of the Rest API call.

5, Secured-communication enablement

MULTICLOUD-518 - Getting issue details... STATUS

uwsgi https option
The multicloud services which are based on uwsgi could utilize the https feature of uwsgi: https://uwsgi-docs.readthedocs.io/en/latest/HTTPS.html
You probably have to rebuild uwsgi with ssl-support:
On a debian server with uwsgi installed by pip this would be (as root):
```
apt-get install libssl-dev
pip install uwsgi -I --no-cache-dir
```
-I for reinstall, --no-cache-dir for building new from scratch.
cert files
     The question would be: who/how to generate key and cert ?
               Follow the practice of MSB project, multicloud service will generate our own keys/certs and put them in the docker by default. And also make sure these keys/certs can be overrided by OOM helm chart , just like the logging settings.
    It is suggested that we follow the same pattern, put the generated certs under pub/ssl/cert/ with name cert.crt and cert.key
ENV variable to enable/disable https on the same port
I don't believe the http and https endpoint should co-exists which make no sense from security perspective. So I recommend that the http/https should be toggled by an ENV variable and binding to the same port
The ENV variable could be: SSL_ENABLED, to enable https endpoint, set SSL_ENABLED=true ; otherwise just leave it unset or set to some other value (SSL_ENABLED=false, e.g.)
The entry point of docker container will check this ENV var and determine to enable https or http mode for uwsgi.
example patch: https://gerrit.onap.org/r/#/c/81829/

6， Security Requirement: Run microservice as non-root user

MULTICLOUD-492 - Getting issue details... STATUS

Reference: https://gerrit.onap.org/r/#/c/78803/

Make sure you test it with healthcheck API

7, Docker image footprint optimization

MULTICLOUD-504 - Getting issue details... STATUS

Reference:

Exercise on multicloud broker: https://gerrit.onap.org/r/#/c/79582/

Local try, observed image size drops from 846MB to 194MB:

dockerfile changes

Image footprint
optimization exercises:

1, original
dockerfile => (multicloud-broker-orig: 846MB)


Dockerfile:


FROM
python:2

2, rebase to
python:2-slim => (multicloud-broker-slim1: 410MB)


Dockerfile:


FROM
python:2-slim

apt-get install -y unzip gcc

pip install -r ...

apt-get remove -y unzip gcc



3, remove unused
packages => (multicloud-broker-slim2: 296MB)


Dockerfile:

FROM
python:2-slim

apt-get install -y unzip gcc

pip install -r ...

apt-get remove -y unzip gcc


/opt/multivimbroker/requirements.txt

#redis cache
#redis==2.10.5

#for access redis cache

#redisco==0.1.4

#django-redis-cache==0.13.1

#for call openstack api
#python-keystoneclient==3.6.0
#python-glanceclient==2.5.0

#python-neutronclient==6.0.0
#for unit test

#django-nose>=1.4.0
#coverage==4.2
#mock==2.0.0
#unittest_xml_reporting==1.12.0

#for pecan framework
#pecan>=1.2.1
#oslo.concurrency>=3.21.0
#oslo.config>=4.11.0
#oslo.service>=1.25.0
#eventlet>=0.20.0


 


4, Remove all unused utils package => (multicloud-broker-slim4: 194MB)
Dockerfile:

FROM python:2-slim
apt-get install -y wget unzip gcc
apt-get --purge remove -y wget unzip gcc
apt-get -y autoremove
 

multicloud-broker-slim4   latest              4452cb69a1be        6 minutes ago       194MB
multicloud-broker-slim2   latest              3c232d46c0fa        10 minutes ago      296MB


multicloud-broker-slim1   latest              5ba81358eb19        16 minutes ago      410MB


multicloud-broker-orig    latest              7601a4382bb0        10 days ago         846MB


python                    2-slim              f2ac6489d817        10 days ago         120MB