Skip to content

Feature request: Support for cloud-native charms

Non-Proxy charms

Proposer

  • Adam Israel

Type

Feature

Target MDG/TF

RO, SO, VCA

Description

Support of non image-based VNFs, deployed via a Juju charm.

OSM Releases 1 and 2 have supported only a subset of the features offered by a charm. In this case, these "proxy" charms have been installed into an LXD container, while the VNF, via a static image, is instantiated by the RO on separate hardware. The SO executes actions in the proxy charm, which execute commands on a VNF via SSH or some kind of VNF-specific API.

Image vs. Cloud-native VNF

This feature would enable support of charms that install and run alongside a VNF on the same hardware. This begins with a standard base cloud image, instantiated by the RO. The SO would then deploy the charm to that instance, rather than to a separate LXD container. The charm, via its hook environment, would then download, install, and configure the VNF. When the charm's state changes to "Active", the SO knows that the VNF is ready for operation.

A "cloud-native" VNF is one capable of being installed on top of a base OS and supports the use of dependent services installed on the same instance or a separate instance, so that the services that make up the VNF are individually scalable.

Relations

Juju relations allow a charm to declare it's support for an interface that encapsulates the operational logic required by two applications to communicate with each other.

For example, a VNF may require a database. One of several database charms (MySQL, MariaDB, PostgreSQL, etc) provide a database. When a relation is joined, both participants are notified so that they can provide any requirements. Next, the providing side of the relation sends the VNF the information required for the relation to be successful, such as the database name, user name, and password.

Implementation

While this feature may seem complex at first glance, all of the hard work has already been implemented in the VCA.

Current workflow:

  1. SO asks RO for an instanced based on a static VNF image
  2. RO provides the SO with a new VNF instance (ip address, etc.)
  3. SO deploys VNF proxy charm
  4. SO configures VNF proxy charm
  5. SO executes actions on VNF proxy charm to configure VNF

Proposed workflow:

  1. SO asks RO for an instanced based on a standard cloud OS image
  2. RO provides the SO with a new instance (ip address, etc)
  3. SO adds instance to VCA (using Juju's manual provider)
  4. SO deploys VNF charm to instance

Demo or definition of done

Following through on the examples in the previous section, here is an illustration of a cloud-native VNF, where only one resource of the AAA VNF is needed, but it's database has been scaled up.

AAA VNF                 MySQL
+---------------+       +---------------+
| ------------+ |       | +-----------+ |
| |  aavnf/0  | +------>| |  mysql/0  | |
| ------------+ |       | +-----------+ |
+---------------+       |       |       |
                        | +-----------+ |
                        | |  mysql/1  | |
                        | +-----------+ |
                        +---------------+

The completion of this feature means that a VNF can leverage any of the existing applications in the Juju Charm store, running the gamut from databases and logging dashboards to Kubernetes and Docker, while maintaining functional separation between the RO/SO/VCA components.