Merge branch 'fixes-gerardo' into 'master'

- `availability_zone`: To be used for the deployment. It can be:

  - a single availability zone (all deployments will land in that zone), e.g. `availability_zone: controller`

  - several availability zones, which enables affinity and anti-affinity deployments, e.g. `availability_zone: [zone1, zone2]`

- `region_name`: The region where the VM must be deployed.

- `region_name`: The region where the VM will be deployed.

- `insecure`: (By default false). When true it allows authorization over a non trusted certificate over https

- `ca_cert`: (incompatible with insecure). root certificate file to use for validating the OpenStack certificate

- `use_existing_flavors`: (By default, `False`). Set to `True` to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where RO still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)

ADVANCED configuration:

- `keypair`: To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair

- `dataplane_physical_net`: The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch.

- `dataplane_physical_net`: The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In Openstack, this is typically configured in `network_vlan_ranges` param as part of neutron ML2 configuration. In case of VMware Integrated Openstack (VIO), it is the ID of the distributed virtual switch.

- `use_floating_ip`: (By default false). When boolean true, a management interface of a VNFD is automatically assigned a floating\_ip -if possible-. If there is not any floating ip avalialble, it tries to get one if there is only one pool. You can use a string `pool_id` (public network id) instead of boolean true, to indicate the pool to use in case there are several. Note that deployment is not aborted if failing to asign a floating ip. The preferred method instead of this is to use a provider network

- `dataplane_net_vlan_range`: In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start\_ID - end\_ID']

- `microversion`: This is an Openstack-only parameter that allows to specify a specific microversion to be used in nova. When using `microversion: 2.32`, it enables the use of Virtual Device Role Tagging, which allows to identify each VM interface with a tag (the tag will be the name of the interface in the VNFD) and convey that information to the VM as metadata. This implementation approach is due to the warning message in <https://developer.openstack.org/api-guide/compute/microversions.html> where it is stated that microversion backwards compatibility is not guaranteed and clients should always require a specific microversion. This functionality was introduced would not work with Openstack versions previous to Newton.

- `vim_type`: Set to `VIO` to use VMware Integrated openstack as VIM.

- `use_internal_endpoint`: When `true` it allows use of private API endpoints.

- `dataplane_physical_net`: (only when applicable) The configured `network_vlan_ranges` at neutron for SR-IOV (binding direct) and passthrough (binding direct-physical) networks, e.g. `physnet_sriov` in the above configuration. In case of VMware Integrated Openstack (VIO) provides more ID of distributed virtual switch, e.g 'dvs-46' in above configuration..

- `dataplane_physical_net`: The ID of the distributed virtual switch e.g 'dvs-46' in above configuration.

- `dataplane_net_vlan_range`: In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format `['start_ID - end_ID']`.

- `vrops_site`: URI of vRealize Operations (vROPS) endpoint used by OSM to get infrastructure metrics.

- `vrops_user`: user of vRealize Operations (vROPS) used by OSM to authenticate against vROPS to read infrastructure metrics.

- `vrops_password`: password of vRealize Operations (vROPS) used by OSM to authenticate against vROPS to read infrastructure metrics.

For common options, you may refer to the general OpenStack Setup Guide.

### Adding kubernetes cluster to OSM

In order to test Kubernetes-based VNF (KNF), you require a K8s cluster connected to a network in the VIM (e.g. `vim-net`). If you have a baremetal installation of Kubernetes, you will need to add a VIM in order to add the Kubernetes cluster.

In order to test Kubernetes-based VNF (KNF), you require a K8s cluster, and that K8s cluster is expected to be connected to a VIM network. For that purpose, you will have to associate the cluster to a VIM target, which is the deployment target unit in OSM.

You will have to add the K8s cluster to OSM. For that purpose, you can use these instructions:

The following figures illustrate two scenarios where a K8s cluster might be connected to a network in the VIM (e.g. `vim-net`):

- A K8s cluster running on VMs inside the VIM, where all VMs are connected to the VIM network

- A K8s cluster running on baremetal and it is physically connected to the VIM network

![k8s-in-vim-singlenet](assets/800px-k8s-in-vim-singlenet.png)

![k8s-out-vim](assets/800px-k8s-out-vim.png)

In order to add the K8s cluster to OSM, you can use these instructions:

```bash

osm k8scluster-add --creds clusters/kubeconfig-cluster.yaml --version '1.15' --vim <VIM_NAME|VIM_ID> --description "My K8s cluster" --k8s-nets '{"net1": "vim-net"}' cluster

- `--description`: Give a description to your Kubernetes cluster

- `--k8s-nets`: It is a dictionary of the cluster network, where the `key` is an arbitrary name and the `value` of the dictionary is the name of the network in the VIM. In case your k8s cluster is not located in a VIM, you could use '{net1: null}'

In some cases, you might be interested in using an isolated K8s cluster to deploy your KNF. Although these situations are discouraged (an isolated K8s cluster does not make sense in the context of an operator network), it is still possible by creating a dummy VIM target and associating the K8s cluster to that VIM target:

```bash

osm vim-create --name mylocation1 --user u --password p --tenant p --account_type dummy --auth_url http://localhost/dummy

osm k8scluster-add cluster --creds .kube/config --vim mylocation1 --k8s-nets '{k8s_net1: null}' --version "v1.15.9" --description="Isolated K8s cluster in mylocation1"

```

### Adding repositories to OSM

You might need to add some repos from where to download helm charts required by the KNF:

osm repo-show bitnami

```

### KNF Service on-boarding

### KNF Service on-boarding and instantiation

KNFs can be on-boarded using Helm Charts or Juju Bundles. In the following section is shown an example with Helm Chart and for Juju Bundles.