Automatic Flavor Creation based on VNFD Template

[Sridhar Ramaswamy]

Request for Enhancement:

Tacker currently supports describing the VM(s) in which VDU(s) using nova-flavor name (or uuid). Few downsides to this approach is,

a) Operators need to pre-create the flavor before using VNF Manager
b) VNF vendors cannot codify their "virtual-machine" requirements (cpu, mem, etc) in the VNFD template they release. Instead they need to resort to documentation to have the operator create them prior to VNF deployement.

To avoid these and make Tacker VNF lifecycle operations smoother Tacker need to support automatically creating flavor based on VNFD machine properties.

Template Enhancement:

Tacker VNFD template should be enhancement based on tosca-nfv profile [1] and, if not available there, using tosca simple profile [2] (nfv profile inherits many attributes from simple profile).

     vdu1:
        host:
          properties:
            disk_size: 10 GB
            num_cpus: 2
            mem_size: 4096 MB

Note, while introducing this capability the existing flavor option should continue to work as is.

[1] http://docs.oasis-open.org/tosca/ns/simple/yaml/1.0/nfv/1.0/
[2] http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html

[bharaththiruveedula (bharath-ves)]

Currently users specify the flavor name in VNFD using 'instance_type' attribute. For example:

vdus:
  vdu1:
    id: vdu1
    vm_image: cirros-0.3.4-x86_64-uec
    instance_type: m1.tiny

But if the user specify the VDU properties like:

vdus:
  vdu1:
    id: vdu1
    vm_image: cirros-0.3.4-x86_64-uec
    properties:
        num_cpus: 1
        disk_size: 10 GB
        mem_size: 1024 MB

Tacker need to create the flavor with these properties. But a few unknowns in this spec:

1)What if the user specify only one property like "num_cpus"? Do we need to provide default values to other properties or raise an error?
2)Syntax to specify the memory unit. For example disk size is always in GB, so just provide number instead <num><unit>?. But if we want to use this approach, the TOSCA template become openstack biased. So I prefer to use <num><unit>. And allow specific units to limit.
3)If the user specify both 'instance_type' and 'properties' in VNFD, do we need to go with 'instance_type' or 'properties'?

And coming to implementation, I think we need a novaclient in tacker. Using novaclient we need to create a flavor. Life cycle of tacker created flavor is same as VNFD associated with it. We can have DB migration to store flavor name/ID in and 'devicetemplateattributes' table or we can add flavor name to template itself.

[bharaththiruveedula (bharath-ves)]

Regarding novaclient, we have the novaclient code in drivers/nova/nova.py. Can we have a new clients.py module to access different openstack clients. Even for automatic network creation, we need neutron client.

[Sridhar Ramaswamy (srics-r)]

Bharath,

Here are some thoughts related to the points you raised,

1) Minimal attributes -
     We need to insist a minimal set of attrs (say cpu, mem, disk ? ) to successfully accept VNFD flavor. Otherwise we need to fail VNFD creation. We should also look at minimal attrs required to create nova flavor as an input.

2) For keywords we should always stick with TOSCA key strings. See here Properties in sec 5.4.3.1
,
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#_Toc430015746

3) For units for both memory (RAM) and disk we need to support all three - KB, MB, GB

4) If both 'instance_type' and actual machine attrs are specified, I'd suggest to ignore the VM attributes and go with 'instance_type'

The implementation flow described - using deviceattributes table and have this tied to VNFD lifecycle seems reasonable to me.

[bharaththiruveedula (bharath-ves)]

Sridhar,

Thanks for the inputs. I have one more issue. We are defining the properties at VDU level. So do we need to create the flavors all the VDUs in the corresponding VNF?

[yong sheng gong (gongysh)]

https://blueprints.launchpad.net/tacker/+spec/automatic-resource-creation

[Sridhar Ramaswamy (srics-r)]

@Bharath - yes, we need flavors, networks, images created using normalized two tuple - "-vnfX-vduY"

[Sridhar Ramaswamy (srics-r)]

Closing this RFE as this is consolidated into a automatic-resource-creation blueprint,

https://review.openstack.org/#/c/250291/