Vladimir, Excellent question. As Alla mentioned we will share an updated set of material in next couple of days per discussion on yesterday’s use case team call. Should hopefully address your question but you have some thoughts already welcome those.
From: [email protected] [mailto:[email protected]] On Behalf Of Vladimir Yanover (vyanover) Sent: Tuesday, October 10, 2017 3:30 AM To: Alla Goldner <[email protected]>; DRAGOSH, PAMELA L (PAM) <[email protected]>; [email protected] P <[email protected]> Cc: [email protected]; [email protected] Subject: [External] Re: [Onap-usecasesub] [Onap-arc] External controller support in Beijing Release If I may ask, what is the abstraction of the “External controller” that ONAP is supposed to follow? Where is it defined? Thanks Vladimir From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alla Goldner Sent: Tuesday, October 10, 2017 8:10 AM To: DRAGOSH, PAMELA L (PAM) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> P <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Onap-arc] External controller support in Beijing Release Thanks, Pam, Here is the updated list with also one typo corrected. 1. AAI, incl. ESR 2. SDC, VNF SDK, Modelling 3. SO 4. VID 5. External API 6. DCAE, HOLMES, Policy, CLAMP Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: DRAGOSH, PAMELA L (PAM) [mailto:[email protected]] Sent: Monday, October 09, 2017 7:05 PM To: Alla Goldner <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> P <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Onap-arc] External controller support in Beijing Release Alla, If you intend to use the External Controller for any control loop use cases then you will need Policy. With that being said, the request from the Policy team is a single common Controller SDK to be implemented by all controllers for performing any type of action on a VM/VNF. And as simplistic an API as possible. The current API implementations for SO/APPC/VFC are overly complicated and require too much interaction with A&AI. Thanks, Pam From: <[email protected]<mailto:[email protected]>> on behalf of Alla Goldner <[email protected]<mailto:[email protected]>> Date: Monday, October 9, 2017 at 11:50 AM To: "[email protected] P<mailto:[email protected]%20P>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [Onap-arc] External controller support in Beijing Release Hi all, We (Usecase subcommittee) would like to initiate a discussion with a different involved projects on potential implementation of External controller in Beijing Release. Next week, we need to present and get a view from the following affected projects: 1. AAI, ESI 2. SDC, VNF SDK 3. Modelling 4. SO 5. VID 6. External API 7. DCAE, HOLMES 8. CLAMP And, of course, from the architecture and modelling subcommittees. (Ramesh, please add any potentially affected projects I may have forgotten). One way is to schedule a new meeting. The alternative way is to ask Chris for Architecture subcommittee meeting’s time and discuss it there ☺ What do you think? Chris, is there any possibility to host this discussion next week? Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=jwTiArcEj6aUX0HjV0M3dT12gUtk7rC07xpgpVZkS_4&m=BPpbIMtWz3IWAh_XsuepRoZss7N0GWC9-v6pYEh_unk&s=r-g9j6tieoh0RKObysLSW_mLXqTV4Ai1PR7UMHXazGE&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=z7a9RxCnpCTOr5e73KITk87n8JtmCnBxUU_VZbci5do&m=KjkXvspJyf63ZIU0wgBvkIHreLGB2XRG7hvf-YjuGSo&s=HLZIAwSMFWQ_XVwph9SGTc-SbYnuFNhWrJPD4SeUC6Q&e=> ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
