Updating AAI upon successful instantiation of resource bundle

Proposal -1:

we will use the vserver to update the pod information in AAI (no.of pods = no.of vservers).

For IP will use the l-interface in the vserver and currently proposing to add five parameters in AAI, as shown in below vserver.json (vserver-name,vserver-name2,prov-status,l3-interface-ipv4-address and l3-interface-ipv4-prefix-length).

Vserver.json

Proposal-2:

Pod names are not fixed. They will always change whenever the pod gets restarted. Remember pods are *NOT* like VMs.

If the goal here is to be able to connect to the POD to do some actions on it, then we are better off storing the Name of the Service that sends traffic to that POD.

Basically, the vserver information should say: "I want to connect to this service within my application and here is the IP and PORT to do so"

The connectivity information will be the Public IP: Port combo for each Kubernetes Service, which will allow you to ssh into the pod itself via the service.

Now, when there are multiple pods for each service, the pods will  need to have to have a mechanism that will allow them to synchronize that information between them. Either via a persistent volume that stores state or via some kind of peer to peer gossip.

The connection flow will be like this. The only thing that is accessible to the outside is the PUBLIC_IP.

ONAP USER --> PUBLIC_IP:PORT --> INGRESS_GATEWAY --> SERVICE:SERVICE_PORT --> ONE OF THE PODS

Having said that, selection of a particular service can be done via route inspection for HTTP services.

For TCP services such as SSH or NETCONF, there is no route and we will have to use PORT based TCP routes.

So, a dynamically generated port will be allocated on the public_IP.

Observations from vFW Closed-loop:

That example has 2 parts:

1. The vFW component sends VES events to the DCAE collector.  In our lab setup, all that was needed was the IP address and port of the DCAE collector – and of course, the vFW pod (virtlet) needs to be able to access that.  The aspect that needs to line up with AAI is the VES event contains a ‘sourceName’ field which is used by DCAE to lookup the corresponding vserver in AAI.  With the current demo vFW code, the hostname of the vFW (virtlet) turns out to be the pod name.  (see https://wiki.onap.org/display/DW/Setting+up+Closed+Loop+for+K8S+vFW+-+initial+pass#SettingupClosedLoopforK8SvFW-initialpass-VESEventsfromthevFirewall for details).

2.  

   1. If you look at my example in the link refered, you’ll note that I did not add any IP address info – it seems the key info is the vserver name and its relationship to the vnf-id.  Obviously IP info is needed for connections coming the other direction.

1. The other part of the vFW closed loop example is the connection made so that APPC can configure the Packet Generator in response to policy.  So far, I have mimicked the steps used by the integration robot testing – and set up the APPC netconf mount to the Packet Generator manually.  The 3 specific data items needed were: vnf-id, IP address and Port number.  In my initial test case, the IP address was the IP of the Node and the Port was the Node Port of a Service (which will be added to the example).    (see https://wiki.onap.org/display/DW/Setting+up+Closed+Loop+for+K8S+vFW+-+initial+pass#SettingupClosedLoopforK8SvFW-initialpass-SettingupaServicethePacketGeneratornetconfmount )

2.  

   1. If I’m following proposal-2 point then eventually, we’d use a Public IP:Port instead of the node values I used.

   2. For the service, the vserver object could be the service name.

   3. Once the netconf mount is done, ONAP just needs to know the vnf-id (I believe – response to policy worked without AAI having any IP info).  So, while I manually performed the netconf mount, if ONAP has the ability to automatically perform the netconf mount, then AAI will need the appropriate information.

So, what if, for example, the vFW needs to send VES events (as in part #1) and it also needs to have configuration (as in part #2)?

Perhaps this implies two vserver objects?

One for the pod name of the pod generating ves events and another for the service and the network interface it exposes.

Also, one other thought, as proposal-2 mentions, the pod name can change – so if pod is used as vserver name, then you’d want some process to update AAI.  Maybe we need to make our sample vFW VES events send something a little less volatile then pod name.