Charms allow OSM to deploy network services with VNF/KNFs that can be configured, integrated, and operated with day-1 and day-2 actions. Charm is software that drives software, and that follows what in the Kubernetes world is known as the _operator pattern_. The VCA (Juju controller) is responsible for deploying, configuring, integrating, and executing actions in the Charms.
Particularly, Proxy charms provide capabilities to add all these benefits to workloads that are “fixed” (i.e. PNFs, VNFs that come with a custom image, and software cannot be installed there, etc). In this case, the Charm/operator lives in a container different from the workload.
Currently, OSM supports two types of Proxy Charms: LXD and Kubernetes charms. With any of the Kubernetes-based installations (charmed or k8s), two clouds will be automatically added to the VCA, which will be afterwards used to deploy LXD and K8s Proxy charms. By default, these clouds are installed in the same machine as OSM, but they can be configured to be external:
```bash
$ juju clouds --controller osm-vca
Clouds available on the controller:
Cloud Regions Default Type
lxd-cloud 1 default lxd
microk8s 1 localhost k8s
```
By default, all LXD Proxy charms will be deployed to the lxd cloud, and all the K8s Proxy charms to the k8s cloud. That behavior can be changed by adding additional clouds to the VCA, and referencing them in the vim account.
### Add clouds to the VCA
Adding clouds to the VCA is a very straightforward process, but the commands are slightly different depending on the target cloud type.
#### k8s
To add a Kubernetes cloud to Juju, we only need the kubeconfig file of the Kubernetes cluster that we will be adding.
**juju add-k8s* command takes the kubeconfig from stdin
* --controller: Controller name is “osm-vca”
* cloud_name: The cloud name that will be assigned to the cloud. By default, the credential name will be the same as the cloud name. Underscores (“_”) or names starting with numbers (“1-9”) are not valid.
* cloud_name: The cloud name that will be assigned to the cloud.
Now we will explain how to build the cloud and credentials files, and obtain all the needed data.
##### **Cloud file**
```yaml
clouds:
<CLOUD_NAME>:
type:lxd
auth-types:[certificate]
endpoint:"https://$LXDENDPOINT:8443"
config:
ssl-hostname-verification:false
```
* CLOUD_NAME: Name of the cloud that will be specified in the _juju add-cloud_ command. Underscores are not valid.
* LXD_ENDPOINT: The endpoint of the LXD cloud, is the URL needed to reach the LXD Nodes. For more information, [go here](https://osm.etsi.org/docs/user-guide/16-lxd-cluster.html), and search for “What IP address or DNS name should be used to reach this node?”.
##### **Credentials file**
```yaml
credentials:
<CLOUD_NAME>:
<CREDENTIALS_NAME>:
auth-type:certificate
server-cert:|
<SERVER_CERTIFICATE>
client-cert:|
<CLIENT_CERTIFICATE>
client-key:|
<CLIENT_KEY>
```
* CLOUD_NAME: Name of the cloud that will be specified in the *juju add-cloud* command.
* CREDENTIALS_NAME: Name of the credentials for the cloud. No underscores or names starting with numbers are valid.
* SERVER_CERTIFICATE: Obtaining the server certificate is as easy as executing the following command in an LXD Node: `$ cat /var/snap/lxd/common/lxd/server.crt`
* CLIENT_CERTIFICATE and CLIENT_KEY: The client key and certificate will be used by Juju, to contact the LXD cloud endpoint. Can be generated like this: `$ openssl req -nodes -new -x509 -keyout client.key -out client.crt -days 365 -subj "/C=FR/ST=Nice/L=Nice/O=ETSI/OU=OSM/CN=osm.etsi.org"`. It is important to trust the certificate in the LXD node: `$ lxc config trust add local: client.crt`
Now that we know how to add LXD and K8s clouds to Juju, we only need to associate specific clouds with the vim account, so all the Proxy charms of the network functions targeting that vim will be deployed in the clouds we select.
Technically, it is possible to add the configuration for only one of the clouds, and the other will point to the default.
The important thing to explain are the four parameters in the configuration of the vim account:
* vca_cloud: Name of the cloud for LXD Proxy charms
* vca_cloud_credential: Name of the cloud credentials for LXD Proxy charms
* vca_k8s_cloud: Name of the cloud for K8s Proxy charms
* vca_k8s_cloud_credential: Name of the cloud credentials for K8s Proxy charms
You can configure the VIM to, instead of using the default lxd and k8s clouds, use clouds hosted in that specific VIM. **[This section](06-osm-platform-configuration.md#Distributed-Proxy-Charms)** explains the details on how to set everything up.
@@ -684,3 +684,163 @@ To **show packages details** available in the repository it is posible use the f
osm nspkg-repo-show --repo vnfrepo <nsd>
```
## Distributed Proxy Charms
Charms allow OSM to deploy network services with VNF/KNFs that can be configured, integrated, and operated with day-1 and day-2 actions. Charm is software that drives software, and that follows what in the Kubernetes world is known as the _operator pattern_. The VCA (Juju controller) is responsible for deploying, configuring, integrating, and executing actions in the Charms.
Particularly, Proxy charms provide capabilities to add all these benefits to workloads that are “fixed” (i.e. PNFs, VNFs that come with a custom image, and software cannot be installed there, etc). In this case, the Charm/operator lives in a container different from the workload.
Currently, OSM supports two types of Proxy Charms: LXD and Kubernetes charms. With any of the Kubernetes-based installations (charmed or k8s), two clouds will be automatically added to the VCA, which will be afterwards used to deploy LXD and K8s Proxy charms. By default, these clouds are installed in the same machine as OSM, but they can be configured to be external:
```bash
$ juju clouds --controller osm-vca
Clouds available on the controller:
Cloud Regions Default Type
lxd-cloud 1 default lxd
microk8s 1 localhost k8s
```
By default, all LXD Proxy charms will be deployed to the lxd cloud, and all the K8s Proxy charms to the k8s cloud. That behavior can be changed by adding additional clouds to the VCA, and referencing them in the vim account.
### Add clouds to the VCA
Adding clouds to the VCA is a very straightforward process, but the commands are slightly different depending on the target cloud type.
#### k8s
To add a Kubernetes cloud to Juju, we only need the kubeconfig file of the Kubernetes cluster that we will be adding.
*`juju add-k8s` command takes the kubeconfig from stdin.
*<controller_name>: Name of the controller to which this cloud will be added to.
*<cloud_name>: The cloud name that will be assigned to the cloud. By default, the credential name will be the same as the cloud name. Underscores (“_”) or names starting with numbers (“1-9”) are not valid.
*<controller_name>: Name of the controller to which this cloud will be added to.
*<cloud_name>: The cloud name that will be assigned to the cloud. By default, the credential name will be the same as the cloud name. Underscores (“_”) or names starting with numbers (“1-9”) are not valid.
*<cloud_file> and <credentials_file>: Path to the cloud and credentials files. The following subsections explain how to build these files.
**Cloud file**
```yaml
clouds:
<CLOUD_NAME>:
type:lxd
auth-types:[certificate]
endpoint:"https://<LXDENDPOINT>:8443"
config:
ssl-hostname-verification:false
```
*<CLOUD_NAME>: Name of the cloud that will be specified in the `juju add-cloud` command. Underscores are not valid.
*<LXD_ENDPOINT>: The endpoint of the LXD cloud, is the URL needed to reach the LXD Nodes. For more information, [go here](https://osm.etsi.org/docs/user-guide/16-lxd-cluster.html), and search for “What IP address or DNS name should be used to reach this node?”.
**Credentials file**
```yaml
credentials:
<CLOUD_NAME>:
<CREDENTIALS_NAME>:
auth-type:certificate
server-cert:|
<SERVER_CERTIFICATE>
client-cert:|
<CLIENT_CERTIFICATE>
client-key:|
<CLIENT_KEY>
```
*<CLOUD_NAME>: Name of the cloud that will be specified in the `juju add-cloud` command.
*<CREDENTIALS_NAME>: Name of the credentials for the cloud. No underscores or names starting with numbers are valid.
*<SERVER_CERTIFICATE>: Obtaining the server certificate is as easy as executing the following command in an LXD Node: `$ cat /var/snap/lxd/common/lxd/server.crt`
*<CLIENT_CERTIFICATE> and <CLIENT_KEY>: The client key and certificate will be used by Juju, to contact the LXD cloud endpoint. Can be generated with the following command: `$ openssl req -nodes -new -x509 -keyout client.key -out client.crt -days 365 -subj "/C=FR/ST=Nice/L=Nice/O=ETSI/OU=OSM/CN=osm.etsi.org"`. It is important to trust the certificate in the LXD node: `$ lxc config trust add local: client.crt`
Now that we know how to add LXD and K8s clouds to Juju, we only need to associate specific clouds with the vim account, so all the Proxy charms of the network functions targeting that vim will be deployed in the clouds we select.
Technically, it is possible to add the configuration for only one of the clouds, and the other one will point to the default.
