diff --git a/04-vim-setup.md b/04-vim-setup.md index 49695d238b52cea1e9335335af2a329290161629..2bc50988e0276b4153e36791e5f0303670d30ba4 100644 --- a/04-vim-setup.md +++ b/04-vim-setup.md @@ -62,7 +62,7 @@ A number of configuration options are supported: - `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) @@ -78,7 +78,7 @@ For OpenStack API v3, the following parameters are required: 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 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. @@ -103,8 +103,11 @@ With respect to a regular Openstack, these additional configuration parameteres - `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. diff --git a/05-osm-usage.md b/05-osm-usage.md index f6d7ff15fb5631b11febad46bbe521ef58cf82df..d432ca7b922e4c95baf97b3ba9ec85cd68c7b0eb 100644 --- a/05-osm-usage.md +++ b/05-osm-usage.md @@ -1172,9 +1172,18 @@ After the Kubernetes installation is completed, you need to check if you have th ### 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 --description "My K8s cluster" --k8s-nets '{"net1": "vim-net"}' cluster @@ -1190,6 +1199,13 @@ The options used to add the cluster are the following: - `--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: @@ -1202,7 +1218,7 @@ osm repo-list 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. diff --git a/assets/800px-k8s-in-vim-singlenet.png b/assets/800px-k8s-in-vim-singlenet.png index f07c6d3a67f1886f212ca8a63fb7ea968b8cf2dc..315381763f8f05e587b82fb193a3f45385085eb7 100644 Binary files a/assets/800px-k8s-in-vim-singlenet.png and b/assets/800px-k8s-in-vim-singlenet.png differ diff --git a/assets/800px-k8s-out-vim.png b/assets/800px-k8s-out-vim.png index eef60ba09e5580065037526f33a0519c97dc1a34..6c16dda7462957cb5f7c5014bba5615db7c9747e 100644 Binary files a/assets/800px-k8s-out-vim.png and b/assets/800px-k8s-out-vim.png differ