Tacker Sending Notifications to VNFC during runtime

Hi Vasu: This is an interesting question. Theoretically it should work, though it would require some intelligence in a script that would talk to Tacker. As you indicate, vnf-update should be able to do this if the wrapper script can take the output from a vnf-show, retrieve the IP information from the mgmt_url column, and format the config data needed for the vnf-update.

Maybe give it a try and let us know if it works.

Hope this helps

Hi Bob,

Thanks for the response.

With tacker vnf-update, It's just adding config data under VNFC1 attributes section like below.

tacker vnf-update --request-format json --config '{"server":"190.168.120.4"}' test
tacker vnf-show test
| attributes | {"config": "{server: 190.168.120.4}\n", "heat_template": "description: demo-example\nheat_template_version: 2013-05-23\noutputs:\n mgmt_ip-vdu1:\n description: management ip address\n value:\n get_attr: [mgmt_port-vdu1, fixed_ips, 0, ip_address]\nresources:\n mgmt_port-vdu1:\n properties: {network: net_mgmt, port_security_enabled: false}\n type: OS::Neutron::Port\n vdu1:\n properties:\n availability_zone: nova\n flavor: m1.tiny\n image: cirros-0.3.4-x86_64-uec\n networks:\n - port: {get_resource: mgmt_port-vdu1}\n - {network: net0}\n - {network: net1}\n type: OS::Nova::Server\n", "param_values": ""} |
| description | demo-example

Is there any way to notify same provided config data to the application running in VNFC1 through tacker?

For Example:

 Suppose VNFC1 is running REST server application, which typically consumes the data provided by REST client through POST operation.
REST Server on VNFC1 Running would be exposing URL for the Clients to POST the data.

The expectation is, when VNFC2 comes up REST Server running on VNFC1 should get notified about the details of VNFC2.

Basically, Tacker would be able to do POST operation to VNFC1 with VNFC2 details.

One approach would be, When ever VNFC2 comes up, VNFC2 it self can trigger one script in run level, which does POST his own details to VNFC1. This script runs REST Client and can be provided as a user_data for VNFC2 with VNFC1 details.
I hope there an option in Tacker VNF template to provide user-data script, please correct me if i am wrong.

But if Tacker is able to POST VNFC2 details directly to VNFC1 using REST URL, then it would be more easier.

Is there any way to handle this kind of scenario in Tacker?

Hi there,

Tacker does support user_data in VNFD templates.

Check https://github.com/openstack/tacker/blob/fb1c08adc54f61fddda902f37d5baf5f7d282b37/tacker/tests/etc/samples/sample-vnfd-single-vdu-monitoring-new-template.yaml a sample template which has user_data section.

You can use this template reference, modify the user_data section to trigger POST requests from VNF2

Hope this helps,
Sripriya

Hi,

Thanks for the reply.

Prior to trigger POST request from VNFC2 user_data script, VNFC2 should know the IPAddress of the VNFC1.

Below the disconnect for me:

How can we get IPAddress of VNFC1 spawned in VNFD yaml template ?

Do Tacker have any mechanism to get the IPAddress of the spawned instances through template.

We can have script which runs vnf-show command to get IPAddress of VNFC1, but it should run from VNFD template

Could you please help me out with sample to get spawned VNFC IPaddress through VNFD template.

One more question: If we want to inject Key Name for VNFC through VNFD template, which field we need to fill.

Thanks,
 Vasu.

Hi Bob,

Below is the sample user_data script for vdu2 or VNFC2

user_data_format: RAW
user_data:
        str_replace:
          template: |
            #!/bin/sh
             post_req.sh $vdu1_ip
          params:
            $vdu1_ip: { get_param: [vdu1, mgmt_uri] } => Need to replace it Tacker equivalent API

{ get_param: [vdu1, mgmt_uri] } or Tacker equivalent api would return the IPAddress of vdu1 or VNFC1.

Thanks,
 Vasu.

Hi Vasu:

If you need the creation of VNFC2 to wait until the IP address assigned to VNFC1 is available, that functionality is not available yet in Tacker. We are hoping to gain the ability to do things like that (dependencies) when we finish implementing the tosca-parser/heat-translator changes that are due this cycle. That will provide all of the capabilities of TOSCA/Heat that are provided by those tools and should (hopefully) address this need.

The work is in progress and we hope to have something available early next year.

The only way to accomplish this now would be to use two different VNFDs, one for each VNFC, or use vnf-update to provide VNFC1's IP address to VNFC2's configuration after deployment.

Hi Bob,

Thank you very much for valuable information.

I just want to know that when we run the tacker vnf-update, will the configuration gets store in running VNF any where, so that any application running on VNF to retrieve ?

Below is the vnf-update command i have used and observed that config data is updated under VNF attributes section.

tacker vnf-update --request-format json --config '{"server":"190.168.120.4"}' test
tacker vnf-show test
| attributes | {"config": "{server: 190.168.120.4}\n", "heat_template": "description: demo-example\nheat_template_version: 2013-05-23\noutputs:\n mgmt_ip-vdu1:\n description: management ip address\n value:\n get_attr: [mgmt_port-vdu1, fixed_ips, 0, ip_address]\nresources:\n mgmt_port-vdu1:\n properties: {network: net_mgmt, port_security_enabled: false}\n type: OS::Neutron::Port\n vdu1:\n properties:\n availability_zone: nova\n flavor: m1.tiny\n image: cirros-0.3.4-x86_64-uec\n networks:\n - port: {get_resource: mgmt_port-vdu1}\n - {network: net0}\n - {network: net1}\n type: OS::Nova::Server\n", "param_values": ""} |
| description | demo-example

Please correct me if i am wrong.

Thanks,
 Vasu.

Hi Bob,

can you tell me when #6 will be supported?

Thanks
Pedro Sousa

Pedro:
    tosca-parser/heat-translator support is in Tacker starting with the Mitaka release. It should be possible to use get_attr to retrieve the IP address of a port for use in a user_data config script on a different VDU, but I don't know that it has been tried yet.

Heat will take care of dependencies so it should just be a matter of making the second VDU dependent on the first (using the get_attr method) so that the IP address is available when the second VDU spins up. It would be a good thing to test.

Vasu:
    Sorry for the long delay. The vnf-update should make the new config data available to the management plugin, which would then need to communicate the update to the VNF/VDU. I think the openwrt plugin probably supports this today.

Hope this helps

Bob