Discussion items
| Duration | Agenda Item | Requested by | Notes / Links |
|---|---|---|---|
| START RECORDING | |||
| Integration Testing for Beijing Status | Control Loop Sub Committee - Beijing Integration Testing Plan | ||
| Casablanca Planning for Scale-Out Use Case | |||
| Request a demo for the complete workflow of service/control loop design and deployment. | People are confused about what's "creating a service" and what's "creating a control loop". As Ron was showing the workflow to us last week, even folks from AT&T started to argue on that, not to mention those who are not from AT&T. | ||
NOTES
Integration Testing for Beijing:
- Pam to Vijay: Policy and DCAE pairwise testing did succeed last Friday. But SB-07 policy had to redo install. Vijay said flow good last weekend verified by Marco. Will check.
- Pam: OOM work still ongoing via the Integration testing calls.
- Vijay: We did as much validation as we could but need OOM gaps to be closed.
- Pam: Policy has more fixes for Policy S3P we are putting into OOM
- Pam: Policy got the released artifacts from AAF and should be able to produce released artifacts for the CLAMP team when LF can get it done.
- Scott: APPC having trouble with DMaap MR. Loading a fix for that now and testing in windriver. Should be ready for pairwise testing today.
- Pam and Randa: Discussed where/when to pairwise test Policy and APPC.
- Randa/Scott: We have our own lab with A&AI, Dmaap and connectivity to OpenStack. Don't have policy.
- Pam: Maybe we test today/tomorrow in Marco environment via Heat. Just do vFW.
- Randa: Would like to get nitrogen in first. Need couple days.
- Ron and Alex presented Beijing Test Plan:
- Blueprints
- Blueprints generated by hand by DCAE project.
- DCAE-DS will not be there until TOSCA Lab done.
- TCA Blueprint is somewhat generic and uploaded as an artifact separate to the different service descriptions into SDC.
- Blueprint distributed as part of the CSAR to both CLAMP and DCAE
- CLAMP deploys a separate TCA instance for each service and creating the initial configuration and operational policy for each instance
- CLAMP is going to test further updates to the thresholds and how the signature is calculated via policy, through dcae policy handler, and show how micro service processes that update. Only 1 policy per micro service. Capability is there for multiple policies but won't be tested
- Q: Is there going to be TCA ms service per service instance or per service template?
- A: All routed through service type. eg. one TCA instance per service type
- Design and Distribute Flow discussed
- Q: When a blueprint distributed to CLAMP, does that widget related to that blueprint automatically shown up on CLAMP UI? Or is development done to show related widgets on CLAMP UI?
- A: Distributed to CLAMP and CLAMP processes the blueprint as an available blueprint design to be configured. Happens automatically.
- Q: Once the blueprint process, it shows up automatically?
- A: Yes
- Q: When a blueprint distributed to CLAMP, does that widget related to that blueprint automatically shown up on CLAMP UI? Or is development done to show related widgets on CLAMP UI?
- Configure and Deploy First Blueprint discussed
- Ron discussed Steps 1-5
- Alex discussed Steps 6 onward
- Q: The blueprint that CLAMP sends to cloudify to install the TCA instance, is that the same blueprint that CLaMP received from SDC? Or is it a new blueprint that CLAMP generated?
- A: CLAMP does not send blueprint, it sends the identifier for the blueprint. DCAE fetches from inventory. Step 1 and 4 shows blueprint distribution.
- Q: The blueprint that CLAMP sends to cloudify to install the TCA instance, is that the same blueprint that CLaMP received from SDC? Or is it a new blueprint that CLAMP generated?
- Flow 3 running the control Loop discussed
- Q: When APPC takes the corrective action there is no feedback from APPC to Policy?
- A: Yes there is. CLAMP is not involved in the runtime CL processing. APPC returns messages back to Policy to receive the request and then a subsequent success/failure. Feedback is back to Policy. DCAE does not receive notification, not in scope. Policy Platform enforces the CL event. The intention is the Operators should be able to change the Operational Policy during runtime to do Health Checks, add more actions, etc.
- Request to update the picture regarding Policy/APPC interaction. Scott volunteered to do this.
- Q: Does TCA send the abatement?
- A: Depends on the use case. Some use case it is not detectable as to whether an abatement occurs. Policy has the option to specify whether abate should be expected or not during execution of Control Loop.
- Q: When APPC takes the corrective action there is no feedback from APPC to Policy?
- Reconfigure Flow discussed
- CLAMP can be used to do any updates to the signature via Policy changes.
- Step 2 onward Alex discussed
- Q: PolicyName via websocket?
- A: Yes
- Q: How long is the polling update for Policy? 15m?
- A: Longest time 30 seconds polling
- Q: Does DCAE publish messages for update on new policy?
- A:
No don't have a mechanism for this.There is a way to verify via CDAP GUI or configuration. Yes it is being logged
- A:
- Blueprints