Per the discussion we had in the SO call today, it sounds to me like the following is possible:
1. Once the current heatbridge gerrits in SO are merged https://gerrit.onap.org/r/78155 , https://gerrit.onap.org/r/78612 a. Steve can move the heatbridge function to it’s own microservice in SO without too much trouble. b. This will support Openstack heatbridge updates for Dublin. 2. If we can enhance the Multicloud workload infrastructure API a bit, then non-Openstack clouds (e.g. k8s) handled via Multicloud can start working on heatbridge-like updates to AAI. a. see https://gerrit.onap.org/r/82183 for suggested API Also, see the wiki for an updated description of the above: https://wiki.onap.org/pages/viewpage.action?pageId=58228881 Thanks, Eric From: Yang, Bin [mailto:[email protected]] Sent: Sunday, March 10, 2019 7:00 PM To: Multanen, Eric W <[email protected]>; [email protected]; [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]>; BLANDFORD, SCOTT <[email protected]> Cc: Addepalli, Srinivasa R <[email protected]> Subject: RE: [onap-discuss] [SO] AAI update (i.e. heatbridge) following vfmodule create Hi Eric, Please refer to my comments below. Thanks 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: Saturday, March 09, 2019 8:59 AM To: [email protected]<mailto:[email protected]>; Yang, Bin; [email protected]<mailto:[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 Cc: Addepalli, Srinivasa R Subject: RE: [onap-discuss] [SO] AAI update (i.e. heatbridge) following vfmodule create Bin Yang, I modified the ‘phase 2 diagram’ on the wiki page to illustrate what I think you’re suggesting. Assuming I’ve captured your idea correctly (alternative step 3a), a few questions come to mind (for anyone to answer): 1. What limitations, drawbacks are introduced by doing step 3a instead of step 3 ? [Bin]: The limitation is step 3 implies there will be a generic/abstract model being agreed on step 2 in case of multiple different VIM/Cloud type, e.g. OpenStack/k8s/azure/etc. . This model should be proposed and reviewed by Modeling subcommittee to make sure it is normalized enough to cover all existing types of VIM/Cloud, as well as being able to extend to cover new types of infrastructure. And any change to this model will requires MultiCloud/SO/AAI to sync up with each other, it could be very problematic hence hindering the implementation/maintenance/evolving … 2. Shouldn’t the data/schema that gets populated in AAI be(come) more or less generic anyway in the long term? [Bin]: Yes, there should be more and more generic in the long term, but should get there in an evolving approach. 3. Or, will resources instantiated in different cloud types be represented differently in AAI ?g [Bin] It could be the case. So far not all AAI objects used by OpenStack plugin are utilized by Azure plugin, I think this is the case for k8s plugin as well. [Bin] One more point, I do not see that SO will consume such data/schema so far (not likely to happen in future), the consumer of such data/schema includes MultiCloud, OOF, APPC/VF-C, etc. That is another point that I think that SO should not be getting involved into such details. Eric From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Yang Bin Sent: Thursday, March 7, 2019 11:39 PM To: Multanen, Eric W <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [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]>>; BLANDFORD, SCOTT <[email protected]<mailto:[email protected]>> Cc: Addepalli, Srinivasa R <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] [SO] AAI update (i.e. heatbridge) following vfmodule create 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]<mailto:[email protected]>; [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Steve Smokowski Sent: Thursday, March 7, 2019 12:25 PM 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: [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 (#16026): https://lists.onap.org/g/onap-discuss/message/16026 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]] -=-=-=-=-=-=-=-=-=-=-=-
