That mediation layer should be designed abstract enough to support longer term of providing standard interfaces, ideally. :-)
Helen Chen Sent from HUAWEI AnyOffice From: [email protected] To: Yunxia Chen; SPATSCHECK, OLIVER (OLIVER); Dhananjay Pavgi; Cc: onap-discuss at lists.onap.org; Subject: Re: [onap-discuss] Support ONAP on multiple OS/Openstacks? Time: 2017-04-20 09:57:15 Short term ? Intermediate layer is REQUIRED. Although longer term ? We shall define standard interfaces so that vendors (VMMs, Cloud etc?) can support this going forward. Thanks From: <onap-discuss-bounces at lists.onap.org> on behalf of Yunxia Chen <[email protected]> Date: Thursday, April 20, 2017 at 8:13 AM To: "SPATSCHECK, OLIVER (OLIVER)" <spatsch at research.att.com>, Dhananjay Pavgi <DP00476350 at TechMahindra.com> Cc: "onap-discuss at lists.onap.org" <onap-discuss at lists.onap.org> Subject: Re: [onap-discuss] Support ONAP on multiple OS/Openstacks? >From architecture wise, I agree with Dhananjay about ?making ONAP agnostic of >underlying virtualization layer?, but in reality, there?re different ?favor? >of VIM from community and vendors, therefore, as in Oliver?s email, ?mediation >Layer? is required to support multi-VIM, such as different version of >OpenStack, AWS, Rackspace, Azure, etc. In OPEN-O community, we supported it by introducing multi-VIM project to handle it. Regards, Helen Chen From: <onap-discuss-bounces at lists.onap.org> on behalf of "SPATSCHECK, OLIVER (OLIVER)" <[email protected]> Date: Thursday, April 20, 2017 at 5:45 AM To: Dhananjay Pavgi <DP00476350 at TechMahindra.com> Cc: "onap-discuss at lists.onap.org" <onap-discuss at lists.onap.org> Subject: Re: [onap-discuss] Support ONAP on multiple OS/Openstacks? It?s the same cloud infrastructure but not the same process flow. Let?s assume for a moment you have an ONAP component which runs on 3 VMs for fault tolerance (that?s not what we have in the demo setup but what you would have in production). In an ideal world you should be able to kill one of the VMs, spin up another one of the same type and the system should be happy again. Today in reality you will have to go into the VM (sometimes more then one) after you spin it up and run various commands to ensure that new VM will be properly integrated with the 2 other once as well as ONAP overall. Not only do you have to run some commands but you will have to run different once depending on the component. Same is true for auto scaling. So as from the cloud layer it?s all the same the cloud layer is not enough. The way to fix that of course is to improve the code in each component so that this becomes fully automatic. The lack of that is a known shortcoming of the current implementation. Oliver On Apr 20, 2017, at 8:08 AM, Dhananjay Pavgi <DP00476350 at TechMahindra.com<mailto:DP00476350 at TechMahindra.com>> wrote: Thanks, Oliver. Absolutely got 1. Below and agreed. Didn?t get 2. Though, i.e. how every component is different when it comes to resiliency features. Ultimately, if it?s same underlying cloud infrastructure, right? thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 <image001.png> <image002.jpg> www.techmahindra.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=N4OP98WhAr1is_7C1Yuy85OhdfcRxPfpekSCn4dhLFE&s=8JDxdisO-ASwqCdy1hE8QP4W_K7KhIdpyFMvSdylENk&e=> Platinum Member. Visit : http://www.onap.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=N4OP98WhAr1is_7C1Yuy85OhdfcRxPfpekSCn4dhLFE&s=WgWBD8QmloguLRSmm6kAScTp_4qyPU1BwtdUIzZl4T0&e=> From: SPATSCHECK, OLIVER (OLIVER) [mailto:[email protected]] Sent: Thursday, April 20, 2017 5:04 PM To: Dhananjay Pavgi <DP00476350 at TechMahindra.com<mailto:DP00476350 at TechMahindra.com>> Cc: LEFEVRE, CATHERINE <cl664y at intl.att.com<mailto:cl664y at intl.att.com>>; onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org> Subject: Re: [onap-discuss] Support ONAP on multiple OS/Openstacks? Dhananjay, I think there are two dimensions ONAP can be improved in this regard. 1. Multi cloud support: To support multiple cloud technologies we not only have to modify the startup automation (heat template) but also adjust the components which work directly with the cloud orchestrator which are MSO, DCAE, App-C and Robotframework for every cloud technology we onboard. So to manage that effectively we should introduce a mediation layer between those 4 components and the underlying cloud technology. There are multiple options out there so that?s not something we have to build from scratch just something we have to pick and integrate. 2. The individual components are still very ?special?. What I mean with that is that each component has it?s own way to provide resilience, disaster recovery and scaling. So if you want to scale out or fail over e.g. the SDN-C controller you do something different then when you scale out DCAE etc? Those difference are visible on the cloud layer which makes this more difficult then it has to be. So we should figure out how to make this more homogeneous. Oliver On Apr 20, 2017, at 4:53 AM, Dhananjay Pavgi <DP00476350 at TechMahindra.com<mailto:DP00476350 at TechMahindra.com>> wrote: Fully agree, Catherine. In addition, should we also consider making ONAP agnostic of underlying virtualization layer e.g. OpenStack, VmWare, OpenVIM etc . Ideally, if cloud native approach is used then this should be taken care of. thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 <image001.png> <image002.jpg> www.techmahindra.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=qY5ElmRuugbIVM9UQVmuBI0vRH_tUKCg0HoRrqxrF2I&s=1yNUJKatHXXDvoRmPtigT-ey1sVtGVIVilkKUH7w9JU&e=> Platinum Member. Visit : http://www.onap.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=qY5ElmRuugbIVM9UQVmuBI0vRH_tUKCg0HoRrqxrF2I&s=nxL8tQrJ68d4Vg2TdSyRE-2cVoOgnc3SyZhebtGK40w&e=> From: onap-discuss-bounces at lists.onap.org<mailto:onap-discuss-bounces at lists.onap.org> [mailto:[email protected]] On Behalf Of Lefevre, Catherine Sent: Thursday, April 20, 2017 2:11 PM To: onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org> Subject: [onap-discuss] Support ONAP on multiple OS/Openstacks? Good morning all, I would like to start a new thread in order to understand if there is a need to certify ONAP on multiple OS/Openstacks. OS Currently ONAP is running on Ubuntu 14.04 (target to move to Ubuntu 16.04). Open-O is running on CentOS but I understand from Helen Yunxia (Huawei) that it should not be an issue to run it on Ubuntu. Redhat was not considered from a certification perspective due to license cost. >From an architecture perspective, it is important that ONAP remains OS agnostic The only constraint on the OS is that it should support an Openstack version OpenStack I have noticed that people are trying to deploy ONAP using different OpenStack release series (i.e. Icehouse, Mitaka, Ocata, Kilo, etc) Although I would like to recommend that we only focus on the release series that are not EOL or will be soon EOL as an Openstack baseline for ONAP, We should collect what has already been validated by the ONAP community and what they agree to support Any additional thoughts? Best regards Catherine Catherine Lef?vre AT&T Software Development & Engineering D2 Platform & Systems Development AVP - ECOMP/ONAP/RUBY/SPP Phone: +32 2 418 49 22 Mobile: +32 475 77 36 73 catherine.lefevre at intl.att.com<mailto:catherine.lefevre at intl.att.com> TEXTING and DRIVING? It Can Wait AT&T BUROGEST OFFICE PARK SA Avenue des Dessus-de-Lives, 2 5101 Loyers (Namur) Belgium NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=qY5ElmRuugbIVM9UQVmuBI0vRH_tUKCg0HoRrqxrF2I&s=a3D50OJabKkrSk5rYScbn3ZKnw25B8HCy7Tynl6d5pQ&e=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=qY5ElmRuugbIVM9UQVmuBI0vRH_tUKCg0HoRrqxrF2I&s=Y14yDpbibIywvVicK_NNBRHzGc-p9R4lQJ_qKsyCu8M&e=> internally within TechMahindra. ============================================================================================================================ _______________________________________________ onap-discuss mailing list onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=qY5ElmRuugbIVM9UQVmuBI0vRH_tUKCg0HoRrqxrF2I&s=Jm40Lsr7fxjN_rlrQnxeY1WB8y5YW7Kev-Moqa6lWeM&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170420/b327baa1/attachment-0001.html>
