diff --git a/06-osm-platform-configuration.md b/06-osm-platform-configuration.md index 5a08473407a500110405204cc20983b0f480be8f..058366da34f7390f32fedd593a1bdcd74c0e5f4b 100644 --- a/06-osm-platform-configuration.md +++ b/06-osm-platform-configuration.md @@ -412,3 +412,233 @@ osm repo-list ### Docker swarm build ### 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: + +- A VNFs is the package that defines the resources needed to allocate the virtual network function described in the VNFD. Each VNFD has at least one VDU (Virtual Deployment Unit). Each VDU is referred to a VIM image that the VIM should host in order to deploy it there when a VNF is instanced. +- The NS package defines, through its descriptor (NSD), how the set of VNFs that compose the service need to be interconnected using the Virtual Links (VL). +- The image is the artefact that enables the deployment of the descriptors in the VDU that will provide the functionality of the service. + +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. + +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 + +Repositories can be hosted locally or exposed through internet. OSM is able to recognice them by HTTP(S). +In both cases, the repository must have the following structure: + +- An `index.yaml` file wich is in charge of indexing the packages +- A specific folder structure (trying to be self-explanatory) +- One artifact's version and its metadata per folder + +#### Structure of the OSM repository: + +The OSM Repository has the following files structure: + +```bash +repository/ + ├── index.yaml + ├── ns/ + │ └── / + │ └── / + │ ├── metadata.yaml + │ └── -.tar.gz + └── vnf/ + └── / + └── / + ├── metadata.yaml + └── -.tar.gz +``` + +The `index.yaml` is in charge of managing the packages' versions and it has the following structure: + +```yaml +apiVersion: v1 +generated: +ns_packages: + : + : + name: + description: + vendor: + path: + latest: + +vnf_packages: + : + : + name: + description: + vendor: + path: + latest: +``` + +One example of an OSM Repository index file could be the following: + +```yaml +apiVersion: v1 +generated: '2020-04-29T13:00:00.690915Z' +ns_packages: + cirros_nsd: + '1.0': + name: cirros_ns + description: Generated by OSM pacakage generator + vendor: OSM + path: /ns/cirros_nsd/1.0/cirros_nsd-1.0.tar.gz + latest: '1.0' + +vnf_packages: + cirros_vnfd: + '1.0': + name: cirros_vnf + description: Generated by OSM package generator + vendor: OSM + path: /vnf/cirros_vnfd/1.0/cirros_vnfd-1.0.tar.gz + '2.0': + name: cirros_vnf + description: Generated by OSM package generator + vendor: OSM + path: /vnf/cirros_vnfd/1.0/cirros_vnfd-2.0.tar.gz + 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: +- Network Service Package `metadata.yaml` example: + +```yaml +vnfd-id-ref: + - cirros_vnfd + - cirros_vnfd +name: cirros_ns +id: cirros_nsd +description: Generated by OSM pacakage generator +vendor: OSM +version: '1.0' +path: /ns/cirros_nsd/1.0/cirros_nsd-1.0.tar.gz +checksum: ebe52f821b0cae896ac29a956da84477 +``` + +- Virtual Network Function Package `metadata.yaml` example: + +```yaml +images: + - cirros034 +name: cirros_vnf +id: cirros_vnfd +description: Generated by OSM package generator +vendor: OSM +version: '2.0' +path: /vnf/cirros_vnfd/1.0/cirros_vnfd-2.0.tar.gz +checksum: e7c9dec0efbab0986afe9e8d64c402f9 +``` + +#### 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: + +```bash +osm repo-index --origin --destination +``` + +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: + +```bash +docker run -v :/repository -p 80:80 luisupm/repository_exporter +``` + +### OSM repository: client side + +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 +osm repo-add --description +``` + +This call will trigger the following actions in OSM: + +1. Save this information in the common database. +2. Invoke the repo_add operation with the known OSM Repository. + +Conversely, a **repo can be removed** with: + +```bash +osm repo-delete vnfrepo +``` + +Likewise, this operation would: + +1. Update the common database accordingly. +2. Invoke the repo_remove operation with the OSM Repository. + +At any moment, it is also possible to get the **list of repos** known by OSM: + +```bash +osm repo-list +``` + +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 + - 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 + +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 + + osm nfpkg-create --repo vnfrepo + ``` + + - NS packages: + ```bash + osm nsd-create --repo vnfrepo + + osm nspkg-create --repo vnfrepo + ``` + +To **show packages details** available in the repository it is posible use the following commands: + +- VNF packages: + ```bash + osm vnfpkg-repo-show --repo vnfrepo + + osm nfpkg-repo-show --repo vnfrepo + ``` + +- NS packages: + ```bash + osm nsd-repo-show --repo vnfrepo + + osm nspkg-repo-show --repo vnfrepo + ``` diff --git a/assets/800px-OSM_repo.png b/assets/800px-OSM_repo.png new file mode 100644 index 0000000000000000000000000000000000000000..3c90d40f55c290df5d86ba7b9b5f12af5f9ccb71 Binary files /dev/null and b/assets/800px-OSM_repo.png differ