Fixed minor format issues in chapter 06

- **`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.

### 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:

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 repositories](./assets/800px-OSM_repo.png)

### OSM repository: server side

- 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/

              └── <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

    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

    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:

```yaml

checksum: e7c9dec0efbab0986afe9e8d64c402f9

```

#### OSM repository generation:

#### OSM repository generation

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:

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:

```bash

```

Once there is a OSM Repository added in the system, it is posible **list packages inside a repository**, by VNF or NS packages:

- VNF packages:

  ```bash

  osm vnfpkg-repo-list

  osm nfpkg-repo-list

  ```

   These comands will retrive a list with all the VNF packages available in the repository 

These commands will retrieve a list with all the VNF packages available in the repository:

- NS packages:

  ```bash

  osm nsd-repo-list

  osm nspkg-repo-list

  ```

   These comands will retrived a list with all the NS packages available in the repository 

These commands will retrieve a list with all the NS packages available in the repository.

To **On-board a package from a repository** to OSM it is possible to use the following commands:

- VNF packages:

  ```bash

  osm vnfpkg-create --repo vnfrepo <vnf>

  osm nfpkg-create --repo vnfrepo <vnf>

  ```

- NS packages:

  ```bash

  osm nsd-create --repo vnfrepo <nsd>

  osm nspkg-create --repo vnfrepo <nsd>

  ```

To **show packages details** available in the repository it is posible use the following commands:

- VNF packages:

  ```bash

  osm vnfpkg-repo-show --repo vnfrepo <vnf>

  ```

- NS packages:

  ```bash

  osm nsd-repo-show --repo vnfrepo <nsd>