Kang, I believe that is ok, but CLAMP needs to be involved.
CLAMP should be involved during Design Time to build those policies and also does the distribution of the blueprint to DCAE controller. CLAMP also makes the API calls into Policy to “deploy” all the Control Loop Policies (Both configuration and operational). I believe you have an outstanding question to CLAMP on their support for this use case. So we need to confirm they will be involved in R1. Otherwise, we would have to use an alternative way to get the policies deployed. But honestly I think they should be able to support this use case for R1. During runtime, our platform would expect to get a control loop event from a DCAE microservice for that specific vG_MUX instance (i.e. the VM ID). Subsequently, the policy platform would then execute an Operational Policy that has the specification to call APP-C to do the Restart. We need to ensure we have the correct vG_MUX instance information to pass to APPC to support their API. Pam From: Kang Xi <[email protected]> Date: Thursday, July 20, 2017 at 9:25 AM To: "DRAGOSH, PAMELA L (PAM)" <[email protected]>, "'[email protected]'" <[email protected]> Cc: "KLUGER, YOAV" <[email protected]>, "TAYLOR, JON" <[email protected]>, Alla Goldner <[email protected]>, Yunxia Chen <[email protected]>, "Yang Xu (Yang, Fixed Network)" <[email protected]>, 'Pawlowski Michal' <[email protected]> Subject: [integration][policy] Policy for vCPE Hi Pam and Policy Team, Based on the previous discussions, we will only need vG_MUX VM restart policy for the vCPE use case for R1. Other requirements would be stretch goals. Currently the vCPE use case wiki page has the following chart showing how to distribute rules to Policy during onboarding. Would you please comment whether this is the most preferred option? Also what tools should be used for policy design? Do we integrate policy design into SDC or the design and distribution are separate from SDC for R1? I’d appreciate if you could get back to me by this Friday. Many thanks. [cid:[email protected]] Regards, Kang
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
