Hi Eric,
I am more interested in understand how we approach to support
“Phase 2 - support non-OpenStack clouds” since the goal of multicloud is to
make ONAP be cloud agnostic (as much as possible). So that’s why we came up
with the proposal to have generic (at template level, not atomic resource
level) infra_workload API . This approach can be easily adapted since it is not
trying to abstract/normalize any resource model from different VIM/Cloud, but
leave the difference being handled by respect multicloud plugin service.
For automating the heatbridge, I wish multicloud could help by
following the same approach: let each multicloud plugin take care of their
interpretation of resource updating to inventory (AAI), but the some other
component (SO, in this case) must determine when to update and which AAI object
(VNF/VF Module) these resources ( e.g. vserver) are associated with. This
approach is not trying to abstract/normalize various resources from different
VIM/Cloud types.
With that, I think the diagram
https://wiki.onap.org/pages/viewpage.action?pageId=58228881 does not work with
this approach: it requires (hence is blocked by) a common/abstract/normalized
model to be defined between SO( heatbridge microservice) , AAI schema, and
MultiCloud plugins(openstack,k8s, azure,etc.) I think this idea could be great
but hard to achieve in short team, and hart to extend in case that new resource
type need to be added from inventory updating perspective.
So again, I prefer that the step 3 is conducted by multicloud
plugin, not by SO(heatbridge microservice) in “Phase 2 - support non-OpenStack
clouds”
My 2 cents.
Best Regards,
Bin Yang, Solution Engineering Team, Wind River
ONAP Multi-VIM/Cloud PTL
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
From: Multanen, Eric W [mailto:[email protected]]
Sent: Friday, March 08, 2019 2:23 PM
To: [email protected]; [email protected]; 'Ahmad, Munir'; 'Byung-Woo
Jun'; 'Seshu m'; 'Subhash Kumar Singh'; Williams, Marcus; 'Muszkieta, Lukasz
(Nokia - PL/Wroclaw)'; 'Milind Jalwadi'; '[email protected]';
BLANDFORD, SCOTT; Yang, Bin
Cc: Addepalli, Srinivasa R
Subject: RE: [onap-discuss] [SO] AAI update (i.e. heatbridge) following
vfmodule create
Thanks again Steve.
See if what I’ve updated here:
https://wiki.onap.org/pages/viewpage.action?pageId=58228881
is cleaner and closer to what you’re thinking (I think it is).
For OpenStack clouds, whether SO Openstack VNF or Multicloud VNF adapter, I
think it can work pretty much the same way with the more or less the code that
has already been written (since, if I’m not mistaken, Multicloud already
supports an OpenStack API).
The big TBD (maybe beyond Dublin) is what I call phase 2 – making things work
for non-OpenStack clouds.
Eric
From: [email protected] [mailto:[email protected]] On
Behalf Of Steve Smokowski
Sent: Thursday, March 7, 2019 12:25 PM
To: Multanen, Eric W <[email protected]>; 'Ahmad, Munir'
<[email protected]>; 'Byung-Woo Jun' <[email protected]>; 'Seshu m'
<[email protected]>; 'Subhash Kumar Singh'
<[email protected]>; Williams, Marcus <[email protected]>;
'Muszkieta, Lukasz (Nokia - PL/Wroclaw)' <[email protected]>; 'Milind
Jalwadi' <[email protected]>; '[email protected]'
<[email protected]>; 'Milind Jalwadi' <[email protected]>;
BLANDFORD, SCOTT <[email protected]>; Yang, Bin <[email protected]>
Cc: Addepalli, Srinivasa R <[email protected]>;
'[email protected]' <[email protected]>
Subject: Re: [onap-discuss] [SO] AAI update (i.e. heatbridge) following
vfmodule create
I don’t see why we cannot have > 1 service talk to a cloud/k8s etc. It seems
that would be the cleanest approach, eventually the MS could go live in Multi
Cloud. For some time we will be supporting both approaches. I don’t know of
anyone running Multi Cloud in production, the VNF Adapter approach is being
used a few deployments.
Thanks
-Steve
From: "Multanen, Eric W"
<[email protected]<mailto:[email protected]>>
Date: Thursday, March 7, 2019 at 2:57 PM
To: "SMOKOWSKI, STEVEN" <[email protected]<mailto:[email protected]>>, "'Ahmad,
Munir'" <[email protected]<mailto:[email protected]>>, 'Byung-Woo Jun'
<[email protected]<mailto:[email protected]>>, 'Seshu m'
<[email protected]<mailto:[email protected]>>, 'Subhash Kumar
Singh' <[email protected]<mailto:[email protected]>>,
"Williams, Marcus"
<[email protected]<mailto:[email protected]>>, "'Muszkieta,
Lukasz (Nokia - PL/Wroclaw)'"
<[email protected]<mailto:[email protected]>>, 'Milind
Jalwadi' <[email protected]<mailto:[email protected]>>,
"'[email protected]'"
<[email protected]<mailto:[email protected]>>, 'Milind Jalwadi'
<[email protected]<mailto:[email protected]>>, "BLANDFORD, SCOTT"
<[email protected]<mailto:[email protected]>>, "Yang, Bin"
<[email protected]<mailto:[email protected]>>
Cc: "Addepalli, Srinivasa R"
<[email protected]<mailto:[email protected]>>,
"'[email protected]'"
<[email protected]<mailto:[email protected]>>
Subject: RE: [SO] AAI update (i.e. heatbridge) following vfmodule create
Thanks for the feedback Steve.
Thinking about your heatbridge microservice idea, it sounds interesting. One
conclusion I come to is it seems like the heatbridge microservice might best
live in the Multicloud project.
See my thinking as follows:
Looking at the gerrit, if I imagine that the current call to
heatbridge(heatStack, cloudSiteId, tenantId, genericVnfName, vfModuleId)
in createVfModule(), were instead an invocation of a new heatbridge
microservice, then the call to that service might be something like:
"Invoke API to heatbridge microservice" (with an appropriate endpoint)
Parameters: workload-id (i.e. heatStackId, etc.), cloud-owner, cloud-region,
tenant-id, genericVnfName, vfModuleId
The two cases I'm interested in understanding is where the SO Multicloud VNF
plugin adapter is used to invoke Multicloud to create vfModules in Openstack
clouds and other (e.g. Kubernetes) cloud types.
Case 1 - Using SO Multicloud VNF adapter with Openstack Workload
Case 1a - heatbridge is performed as part of the vfModule create (no new BPMN
heatbridge step)
The Multicloud openstack plugin (in Multicloud project) after creating stack in
the destination cloud, makes the call the heatbridge microservice to perform
the AAI update.
This seems like it could work ok - but, one issue I'm not clear on is it now
looks like there are now two services (Multicloud openstack plugin and the
Heatbridge microservice) that need to connect/interact with the Openstack
cloud. Does this imply that the Heatbridge microservice should become part of
the Multicloud project?
Case 1b - heatbridge is performed as a separate step after the vfModule is
created (a new BPMN workflow step)
The Multicloud project is invoked with a new API call (such as the one I
suggested on the wiki).
The Multicloud openstack plugin receives the request and, as in case 1a,
invokes the heatbridge microservice. Same question as in case 1a, how to avoid
multiple services needing to talk to the same Openstack cloud (unless it's all
part of the same service)?
Case 2 - Using SO Multicloud VNF adapter with a Kubernetes workload
Case 2a - AAI update (heatbridge) is performed as part of the vfModule create
The Multicloud kubernetes plugin, after creating the vfModule workload in the
Kubernetes cloud, invokes the heatbridge microservice. Now (I assume), the
heatbridge microservice must have some kind of plugin design, since it must be
capable of querying the Kubernetes cloud region to find the workload details
and then map those results to the AAI schema. Again, this suggests that the
heatbridge service might be most conveniently located with Multicloud.
Case 2b- AAI update (heatbridge) is performed as a separate step after the
vfModule is created 9a new BPMN workflow step)
Similar to case 1b, with same observations as case 2a - the heatbridge
microservice needs Kubernetes capable plugin code to interact with the
Kubernetes cloud region and map the workload detail results in to the AAI
schema.
Note - I split the above 2 multicloud VNF adapter cases into a) and b). I
could imagine a phased approach where a) is done first and b) is implemented
later. Either way, it looks like that choice is fairly independent of the
heatbridge microservice question/issue.
Regarding your other question:
What is this API doing? This is statusin multi-cloud or AAI?
Enhance existing Multicloud query to support AAI update status (e.g.
AAI_UPDATE_IN_PROGRESS, AAI_UPDATE_COMPLETED, ...)
This is the API that the SO Multicloud VNF plugin adapter uses to query
Multicloud for workload (e.g. stackId) status. Today that is used to find out
from Multicloud when the stack creation in Openstack is complete.
The thought here was to use the same query to get the status of the AAI update
from Multicloud as well.
From: SMOKOWSKI, STEVEN [mailto:[email protected]]
Sent: Thursday, March 7, 2019 5:47 AM
To: Multanen, Eric W
<[email protected]<mailto:[email protected]>>; 'Ahmad, Munir'
<[email protected]<mailto:[email protected]>>; 'Byung-Woo Jun'
<[email protected]<mailto:[email protected]>>; 'Seshu m'
<[email protected]<mailto:[email protected]>>; 'Subhash Kumar
Singh' <[email protected]<mailto:[email protected]>>;
Williams, Marcus <[email protected]<mailto:[email protected]>>;
'Muszkieta, Lukasz (Nokia - PL/Wroclaw)'
<[email protected]<mailto:[email protected]>>; 'Milind
Jalwadi' <[email protected]<mailto:[email protected]>>;
'[email protected]'
<[email protected]<mailto:[email protected]>>; 'Milind Jalwadi'
<[email protected]<mailto:[email protected]>>; BLANDFORD, SCOTT
<[email protected]<mailto:[email protected]>>; Yang, Bin
<[email protected]<mailto:[email protected]>>
Cc: Addepalli, Srinivasa R
<[email protected]<mailto:[email protected]>>;
'[email protected]'
<[email protected]<mailto:[email protected]>>
Subject: Re: [SO] AAI update (i.e. heatbridge) following vfmodule create
We posted a patch that rewrites Munir’s proposal to use the AAI Client, we
would like that version to be used, as we do not wish to support multiple AAI
clients. In other realms have called it something like cloud inventory
update/orchestration( the “heat bridge”). I am not clear on what modifications
you are proposing here to heatbridge?
What is this API doing? This is statusin multi-cloud or AAI?
Enhance existing Multicloud query to support AAI update status (e.g.
AAI_UPDATE_IN_PROGRESS, AAI_UPDATE_COMPLETED, ...)
Why don’t you must move heatbridge into a microservice and let SO VNF Adapter
call it, and multi cloud call it? I am not clear on this approach, this would
support both paths fairly easily.
Thanks
-Steve
From: "Multanen, Eric W"
<[email protected]<mailto:[email protected]>>
Date: Thursday, March 7, 2019 at 1:48 AM
To: "'Ahmad, Munir'" <[email protected]<mailto:[email protected]>>,
'Byung-Woo Jun'
<[email protected]<mailto:[email protected]>>, 'Seshu m'
<[email protected]<mailto:[email protected]>>, "SMOKOWSKI,
STEVEN" <[email protected]<mailto:[email protected]>>, 'Subhash Kumar Singh'
<[email protected]<mailto:[email protected]>>,
"Williams, Marcus"
<[email protected]<mailto:[email protected]>>, "'Muszkieta,
Lukasz (Nokia - PL/Wroclaw)'"
<[email protected]<mailto:[email protected]>>, 'Milind
Jalwadi' <[email protected]<mailto:[email protected]>>,
"'[email protected]'"
<[email protected]<mailto:[email protected]>>, 'Milind Jalwadi'
<[email protected]<mailto:[email protected]>>, "BLANDFORD, SCOTT"
<[email protected]<mailto:[email protected]>>, "Yang, Bin"
<[email protected]<mailto:[email protected]>>
Cc: "Addepalli, Srinivasa R"
<[email protected]<mailto:[email protected]>>,
"'[email protected]'"
<[email protected]<mailto:[email protected]>>
Subject: [SO] AAI update (i.e. heatbridge) following vfmodule create
Hi Seshu (and anyone else interested in the topic),
Based on feedback I got from Bin Yang, I updated the AAI update (e.g.
heatbridge) proposal for the SO generic cloud support.
See:
https://wiki.onap.org/pages/viewpage.action?pageId=58228881<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D58228881&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=CvgE2TJbS95KPVCWLsjxChIfPeLgQ5sWFLouC0gBC34&s=nfy-MZo0KgWraclyIQ7uOoTYA67_xVy3GdB1dpr-jII&e=>
There are a few key issues that should be resolved soon:
1. API updates provided by Multicloud (consumed by SO)
2. Agreement that a workflow step for AAI update should be added and
possible enhancement to the VNF adapter API so support it
3. Can Munir’s gerrit
(https://gerrit.onap.org/r/#/c/78155/<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_78155_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=CvgE2TJbS95KPVCWLsjxChIfPeLgQ5sWFLouC0gBC34&s=Xuq4yr7sBXMRPjwEx-5sNJlvw7_cQ6i0QCkiHonRMhQ&e=>)
be adapted to align with this proposal
4. Any other issues with the proposal
Thanks,
Eric
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15927): https://lists.onap.org/g/onap-discuss/message/15927
Mute This Topic: https://lists.onap.org/mt/30295164/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
