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]>; '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: [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 (#15919): https://lists.onap.org/g/onap-discuss/message/15919
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]]
-=-=-=-=-=-=-=-=-=-=-=-
