Hi Chris,
This is the update on the following action and progress on this
"Representation and Identification of a cloud region in ONAP" issue.
I had reached out to PTL of VID/SO/SDNC/Integration team and join weekly
meetings of each project. I briefed this issue again on those meetings and
brought attentions of each project team.
VID team agreed that it is doable to fix this issue but need to evaluate the
effort.
SDNC team promised to evaluate the impact and effort to fix this issue.
Integration team acknowledged this issue and Helen preferred the long term
solution.
SO team preferred long term solutions as well, and Seshu suggest we fix this
issue by some use case in future releases.
Since we have passed the M3 API freezing milestone, I think this is not likely
to get this issue resolved in Beijing release.
So I would like to have your suggestion on how to proceed : should we propose
some use case, or make sure some use case in Casablanca Release could cover the
feature to resolve this issue?
Thanks.
Best Regards,
Bin Yang, Solution Readiness Team, Wind River
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
From: [email protected]
[mailto:[email protected]] On Behalf Of Yang, Bin
Sent: Monday, March 05, 2018 10:12 AM
To: [email protected]; Sonsino, Ofir; TIMONEY, DAN; Yunxia Chen
<[email protected]> ([email protected]); PUTHENPURA, SARAT (SARAT)
Cc: Christopher Donley (Chris) ([email protected]); Hellmann, Gil;
[email protected]
Subject: [onap-discuss] Issue to be resolved: Consistent Representation and
Identification of a cloud region in ONAP
Hello Seshu, Dan, Helen, Sarat,
and those are concerned on Representation and Identification of a cloud region
in ONAP,
The expanding to multiple clouds is a key metric for success of
ONAP, and you might already be aware the fact that: With ONAP Amsterdam
release, it is kind of tricky and error prone to onboard a new cloud region
into ONAP for the end-to-end test cases.
I had learned that fact and got plenty help from this community during setting
up a demo of using ONAP to orchestrate the Clearwater vIMS across 2 cloud
regions. So I posted the workarounds on wiki:
https://wiki.onap.org/pages/viewpage.action?pageId=25431491
At the same time, I had presented this issue and the short term
workaround and long term solution to ONAP community during both VF2F meeting
and ONAP Arch meeting. I got suggestion from Chris Donley and Stephen that we
need figure out if it is possible to fix that in Beijing release. So that is
why I come to you and wondering if I can get your kindly support. The summary
of issue and the solutions can be found at wiki:
https://wiki.onap.org/download/attachments/25429038/HowToAddNewCloudRegionAndThoughts.pdf?version=2&modificationDate=1520214136460&api=v2
To highlight what the issue is and what the help is expected from your teams:
1, There are multiple places to represent a single cloud region
and inconsistent identification of a cloud region makes it is hard to onboard a
new cloud region
2, The short term workaround places another constraint on the
"cloud-owner", while the long term solution impose the API changes between
VID/SO/SDNC, and perhaps OOF as well.
Please let me know if you can add this as an agenda to your weekly meeting this
week so that I can explain more the details and estimate the possibility to fix
that in Beijing release.
Thanks.
Best Regards,
Bin Yang, Solution Readiness Team, Wind River
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
