8/3/18 - Traffice Migration Weekly Minutes
Participants: Ajay Mahimkar, Scott Seabolt, Takamune Cho, Lukasz Rajewski, Osinski Tomasz, David Ho.Jacques Bolduc
Minutes:
1, Define Traffic Migration LCM API in APPC: the API input/output. Owner : Orange / Ajay by 8/15
2, code review no later than next Wed (8/8), Orange will provide the deck for code review
3, ODL/Karaf upgrade by 8/10, no submission before 8/10
4, Important date for R3; M3 8/23 API Freeze, M4 9/20 Code Freeze
5, implementation using Ansible for Traffic Migration LCM API in APPC. The date will be decided later
Note:
Playbook will be submitted in CCSDK repo,
Backup plan: using SDNC with ansible server, if time restrained to implement Traffic Migration LCM API in APPC.
8/14/18 - Traffice Migration Minutes
From: BOLDUC, JACQUES
Here is how I envision what we could do for Casablanca, based on the test setup/config that Ajay described.
Traffic to one or multiple VNFs is distributed by a Traffic Distribution/Balancing Entity. We want to tell that Entity what the traffic distribution should be...like 0% VNF1 – 100% VNF2, 30% VNF1 – 70% VNF2, 100% VNF1 – 0% VNF2. If we have more VNFs we have % for each of the VNFs.
Traffic Distribution/Balancing Entity ---------------- VNF1
|
---------------- VNF2
ONAP controller assumes that the VNFs / entities it communicates with have been instantiated by ONAP. I doubt that it is the Traffic Distribution/Balancing Entity if it is a lab traffic generator box but let’s assume for the time being that it has been instantiated by ONAP. Worst comes to worst, the playbook that interacts with the Entity will have to be told what entity it is in a different way than an ONAP VNF ID for our test.
I suggest we add one more LCM API action to control Traffic Distribution/Balancing. Let’s call it “DistributeTraffic” action, a new action supported by LCM API ( see ONAP’s http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20LCM%20API%20Guide/APPC%20LCM%20API%20Guide.html for current actions supported, standard LCM Request header, etc.) . FYI, other actions already supported include QuiesceTraffic, ResumeTraffic. So, we would add DistributeTraffic action to ONAP LCM API.
The DistributeTraffic action would provide the VNF ID of the Traffic Distribution/Balancing Entity, in the ‘action-identifiers’ section of the LCM Request. In the “payload” section of the request we could have a “DistribConfigName” parameter. SDNC/APPC Controller would handle the command and would send message to Ansible server to invoke an Ansible Playbook. The playbook would read a Traffic Distribution Configuration file associated with the DistribConfigName value sent by the Controller. Note: If we want to test/try various traffic distributions (many tests), we could have many Traffic Distribution Configuration files, each with it own DistribConfigName. The Ops/SME responsible for the traffic distribution entity/node would have put the Traffic Distribution Configuration file at the right direction location / dir path so that the Playbook can access it, read the config data and send it to the Traffic Distribution/Balancing Entity to configure the entity with the new traffic distribution config. The Playbook could also include a step to take a backup of the Traffic Distribution/Balancing Entity current traffic distrib/configuration and save it locally at some dir path. If the new traffic distribution action is rejected/failed then the playbook can restore previous traffic distribution/config. The Playbook can offer lots of flexibility and it is up to the entity SME to decide what he/she wants to do upon a DistributeTraffic action request.
Notice that until now, no action has been performed on VNF1 and VNF2. If after or before the DistributeTraffic action (to the Traffic Distribution/Balancing Entity) the SME/Ops expert wants to do some traffic action on VNF1 or VNF2 then we can use different LCM API traffic action(s) to do so. For example, if prior to our test traffic is 100% on VNF1 , VNF2 has just been recently instantiated but not really started (0% traffic), maybe we need to send a StartTraffic / ResumeTraffic LCM API action to allow VNF2 to handle traffic. Then our workflow / test steps would include a StartTraffic / ResumeTraffic LCM API action prior to the DistributeTraffic action.
I do not think it is difficult to add DistributeTraffic action to the LCM API if it is simple payload parameter, like in QuiesceTraffic or ResumeTraffic. If needed, we can also include StartTraffic and StopTraffic actions too. I would think that SDNC PTL/Devs can work with Orange to implement. Orange can gain experience that way. I assume that we can write Playbook(s) for actions required.
8/23/18 - Traffice Migration (Rename to DistrubuteTraffic) Weekly Minutes
Participants: Ajay Mahimkar, Takamune Cho, Lukasz Rajewski, Lathishbabu Ganesan
Minutes:
1, review the deck from Orange
2, Taka will provide the details for CDT code change next meeting (target date: 8/28)
3, Important date for R3; Code submission 9/6, M4 9/20 Code Freeze
4, APPC will have APPC's Ansible server container
Deck:
8/31/18 - DistrubuteTraffic Weekly Minutes
Participants: Ajay Mahimkar, Takamune Cho, Lukasz Rajewski, Lathishbabu Ganesan
Minutes:
1, Important date for R3; Code submission 9/6, M4 9/20 Code Freeze
2, Orange starts to submit the code
3, Ajay will help the access for Windriver Labs
4, Please Join RocketChat if you want to collaborate online. You need to be added to the group chat, but you need to create a username in RocketChat first,otherwise we can't add you.http://52.168.69.155:3000/group/onap-appc