Hi Oliver , Catherine, and all,
Glad to see that the ONAP team initiate the conversation over
the Multiple Cloud support.
Nevertheless making the ONAP services being Cloud agnostic introduces
non-trivial effort and risks on refactoring the ONAP services. considering that
the ONAP community will drive hard to merge projects and get the first release
ready as soon as possible, it is well worth to start the refactoring work over
the carrier grade OpenStack to minimize the effort and risk of setup/debugging
the OpenStack itself.
Titanium Cloud is the Carrier grade OpenStack delivered by Wind River which is
compliance to OpenStack releases, including but not limited to Kilo, Mitaka,
Newton and more. Wind River. Wind River is willing to support ONAP evolvement ,
so Titanium Cloud could be your best candidate to validate ONAP services: free
of charge for ONAP validation effort, along with strong support from Wind River.
Once the ONAP is validated over Titanium Cloud, it could be
validate again on vanilla OpenStack without any extra effort on ONAP side.
Besides the ONAP services themselves, it is also worth to think
about the multiple VIM support to enable ONAP orchestrate VNFs on different
VIMs without pains. Just like what the OPEN-O is doing , the MultiVIM projects
makes the end-to-end test over multiple Cloud very easy and happy.
The MultiVIM project in OPEN-O abstracts the interfaces and
information models between the orchestrator and VIMs, the value of it could
include but not limited to:
1, catalog the NFVI capabilities from the perspective of ONAP, so that VNF
providers could make assumptions the runtime context while designing/developing
VNFs.
2, Enable the ONAP certificate & compliance tests of NFVI vendors/providers
3, Decouple ONAP from specific NFVI while making the possibility of ONAP to
evolve to leverage new capabilities of NFVI, e.g. enabling ONAP to utilize the
EPA (Enhanced Platform Awareness) features that the NFVI offers for some
performance critical VNFs
Best Regards,
Bin Yang, Solution Readiness Team, Wind River
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
From: onap-discuss-bounces at lists.onap.org
[mailto:[email protected]] On Behalf Of SPATSCHECK, OLIVER
(OLIVER)
Sent: Thursday, April 20, 2017 8:46 PM
To: Dhananjay Pavgi
Cc: 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.
