External affinity-or-antiaffinity groups

Proposers

• Francisco Rodríguez (Indra)
• Alexis Romero (Indra)

Description

In some cases, it is necessary to ensure that some VDUs in a Network Service are not collocated with other VDUs in a different Network Service or VNF. For instance, due to lifecycle management constraints, a big network function may be deployed using several Network Services, but it is needed that all VDU of the same type are spread across available hosts. As an additional real example, two load balancers of different NS of the same type needed to be on different machines to be able to tap the traffic between them in an external switch.

Notice the difference with feature #10906 (closed) in which the affinity or anti-affinity applies at the single VNF level.

One way to achieve this, and even more use cases, is to specify the use of a pre-existing "affinity or anti-affinty group" in the vim using instantiation parameters, instead of creating one during the deployment as specified inside the descriptor

For instance

--config '{vnf: [{member-vnf-index: "1", vdu: [{id: mgmtVM, affinity-or-anti-affinity- group: [{id: < server-group-id >}]}]}]}'

where is an existing server group (in Openstack) or the equivalent concept in another VIM type.

Demo or definition of done

Create (outside OSM) a server-group in Openstack with a specific name and affinity or anti-affinity policy.

Deploy a Network Service with --config specifying that one of the VDU belongs to that server group, using the syntax above.

After instantiation, check in Openstack that the server instance is in the specified group.

After deletion, check that the server-group still exists but is empty (no servers assigned)