@@ -133,7 +133,6 @@ The Keystone component will configure itself at startup time using a few environ
-**`LDAP_TLS_REQ_CERT`**: Defines how the certificates are checked for validity in the client (i.e., Keystone end) of the secure connection (this doesn’t affect what level of checking the server is doing on the certificates it receives from Keystone). Possible values are "demand", "never", and "allow". The default of demand means the client always checks the certificate and will drop the connection if it is not provided or invalid. never is the opposite—it never checks it, nor requires it to be provided. allow means that if it is not provided then the connection is allowed to continue, but if it is provided it will be checked—and if invalid, the connection will be dropped.
-**`LDAP_TLS_CACERT_BASE64`**: CA certificate in Base64 format (if you have the PEM file, text inside `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags).
## VIM management
TODO: Page in elaboration.
...
...
@@ -413,7 +412,6 @@ osm repo-list
### Kubernetes build
## OSM Repositories
The Network Services are described as network functions that can be composed, to provide more complex NaaS; several components describe the function as NSD, VNFD and VIM images. These are packaged encapsulating all necessary information in addition to the descriptor file:
...
...
@@ -424,11 +422,10 @@ The Network Services are described as network functions that can be composed, to
Based on this information, It is crucial to have a clear knowledge on how this information is stored and the mechanisms to retrieve it by OSM to onboard and instantiate the Service in the underlying infrastructure. Accordingly, and in contemplation of alleviate the consumption of the NS in a standardized way, a distribution mechanism and efficient packaging standard is introduced as a new feature to be published.
The OSM Repository brings several improvements on the management and consumption of Network Services and the interaction with the repository. This section defines a standardized model format to implement a consumption mechanism for a remote NS repository, that could be queried and managed by OSM abstracting from the actual storage mechanism; the interface will be exposed by HTTP requests.
The OSM Repository brings several improvements on the management and consumption of Network Services and the interaction with the repository. This section defines a standardized model format to implement a consumption mechanism for a remote NS repository, that could be queried and managed by OSM abstracting from the actual storage mechanism; the interface will be exposed by HTTP requests.
This approach will allow other NS developers for publishing and onboard their services, pushing local artefacts and dependencies of the VNFs to the remote repository. The following figure depicts the interconnection between the OSM and the external standardized repository.
### OSM repository: server side
...
...
@@ -440,13 +437,13 @@ In both cases, the repository must have the following structure:
- A specific folder structure (trying to be self-explanatory)
- One artifact's version and its metadata per folder
#### Structure of the OSM repository:
#### Structure of the OSM repository
The OSM Repository has the following files structure:
The OSM Repository has the following file structure:
```bash
repository/
├── index.yaml
├── index.yaml
├── ns/
│ └── <ns_id>/
│ └── <ns_version>/
...
...
@@ -459,7 +456,7 @@ repository/
└── <vnf_id>-<vnf_version>.tar.gz
```
The `index.yaml` is in charge of managing the packages' versions and it has the following structure:
The `index.yaml` is in charge of managing packages versions and has the following structure:
```yaml
apiVersion:v1
...
...
@@ -483,7 +480,7 @@ vnf_packages:
latest:<vnf_pkg_latest_version:String>
```
One example of an OSM Repository index file could be the following:
Here is an example of OSM Repository index file:
```yaml
apiVersion:v1
...
...
@@ -512,7 +509,8 @@ vnf_packages:
latest:'2.0'
```
Finally, the last configuration file is the `metadata.yaml`. This file has the most valuable data of a package. This file is in the same root of the package that descibed and its content is the following:
Finally, the last configuration file is the `metadata.yaml`. This file has the most valuable data of a package. This file is in the same root of the package that described and its content is the following:
- Network Service Package `metadata.yaml` example:
For generating an OSM Repository automatically, the OSM Client provides a useful command in charge of the ETL required to convert a directory containing packages and sources into an OSM repository. This command is the same as to create a repository or update the existing OSM Repository with more packages:
...
...
@@ -550,7 +548,7 @@ For generating an OSM Repository automatically, the OSM Client provides a useful
osm repo-index --origin <packages_folder> --destination <repository_folder>
```
Once It is executed we can find in the destination folder the directory to be exposed via HTTP.
Once it is executed we can find in the destination folder the directory to be exposed via HTTP.
With the following docker container it is pretty easy to expose a directory via http:
From the OSM client, It is possible to manage the usage of the repositories in OSM. Through simple commands we can associate repositories, list the artefacts available in them and onboard packages from the repository. The following commands will describe in detail the functionalities that the OSM Client can deal with the OSM Repositories:
In order to **add a new repo**, the user should invoke the following command:
