Skip to content

Feature proposal: Distributed VCA

Distributed VCA

Proposer

David Garcia (Canonical)

Type

Feature

Target MDG/TF

osmclient, NBI, LCM, N2VC

Description

This feature aims to decentralize the VCA and enable the association between a vim and a Juju Controller. Therefore, all charms of a vim, will be managed by the associated VCA.

With the current design, OSM only supports talking only to one Juju controller, which is responsible for managing all charms in that OSM cluster.

The feature 9952 (Distributed Proxy charms) allows to move the proxy charms to the VIM, so these are closer to the VNFs, but still everything is managed by only one Juju Controller.

Enable having the Juju Controller (VCA) distributed across different VIMs. The main advantage provided by this feature is that charms from network services of different VIMs could be independently managed by different Juju Controllers.

This feature will allow the users with system_admin role in a project to register and manage VCAs so users with either project_admin or project_user roles are able to select one of them when creating a vim account.

Assumptions for the VCAs to be registered into OSM:

  • The VCA must be already bootstrapped before registering it to OSM. See documentation.
  • Distributing the VCA means also distributing the Proxy charms that will be associated with that controller, meaning that as part of the VCA configuration, both lxd and k8s clouds will need to be properly deployed and associated with the controller. See documentation for Distributed Proxy charms.
  • The VCA can be bootstrapped on any cloud (bare metal, k8s, openstack, etc.), but there are several networking constraints that need to be considered:
    • The VCA needs to be reachable from the OSM cluster
    • The VCA needs to be reachable from the Proxy/Native charms deployed by it

The list of VCAs are project-scoped, which means that when a system_admin adds a VCA, this one will be available for all users of the project.

Now we cover the changes needed in each module. You can find more information in the design etherpad for this feature.

Changes in osmclient: New methods need to be added for adding, deleting, editing, and updating VCAs

Changes in NBI: New API calls need to be added to NBI for each of the new osm commands.

Changes in LCM and N2VC: At the time of creating/registering the execution environment, LCM needs to check the config for the vim account, to see if a vca was specified for that account. If so, pass the correspondent object with the connection data to the N2VC, so the connection to the right controller can be made.

N2VC will need to properly store the VCA related data in the mongodb database,
upgrade the endpoints for scaling as it does with the default VCA, and accept a
controller= option in all functions exposed that will need it, to override
the default VCA with the one specified in the vim account.

Definition of done

Once this feature is implemented a system_admin user will be able to register VCAs to OSM which will be visible for project_admin and project_users in the project. Then, the project users will be able to select a vca from the list of available VCAs.