The current self service resolution has the capability to resolve multiple parameters based on the complex data type definitions defined at root level from single request. ( for rest and DB )I will post some samples later. > On Aug 30, 2018, at 11:28 AM, Alexis de Talhouet <[email protected]> > wrote: > > To be very clear, this is not something for Casablanca, as there is no driver > yet. But could be something for Dublin if we extend the self-serve capability > to more use-cases. > > Regarding what should be done in SDNC, is there a agenda for occurring > meeting where I can add a bullet point, so we can start live discussion on > that topic. Based on discussion, we can either plan for Dublin, or see what > can be done in a later stage. > > Alexis > >> On Aug 30, 2018, at 11:06 AM, FREEMAN, BRIAN D <[email protected]> wrote: >> >> Its a good design discussion and inside SDNC I think we need to do somehting >> like a mesh/template processing to make it generic. >> Obviously back to SO we are past M3 so we arent changing that API (and it >> wouldnt fit with the way VIM’s deal with parameters anyway) >> >> Brian >> >> >> From: Alexis de Talhouët <[email protected]> >> Sent: Thursday, August 30, 2018 10:49 AM >> To: FREEMAN, BRIAN D <[email protected]> >> Cc: [email protected]; MALAKOV, YURIY <[email protected]>; TIMONEY, >> DAN <[email protected]>; CHEUNG, PAT <[email protected]>; SINGH, AJAY >> <[email protected]>; ALBETAR, AMMAR <[email protected]> >> Subject: Re: [onap-discuss] [CDS][SDNC] - Modification of >> GENERIC-RESOURCE-API to support capability with multiple return values >> >> Yes, absolutely. >> Instead of forcing the design to have one query for one parameter, I’d like >> to be able to also handle having one query for multiple parameters. >> Say I need 4 sets of (ipaddress, gateway, prefix), I envision to have 4 >> queries to the same capability resolving the list of 3 params 4 times. >> >> I understand what SO expects, and there is no reason why this should change. >> The change could only occur within SDNC to accommodate resource resolution, >> we could flatten the returned map to a single list. >> This could bring more complexity to the name in environment parameters, such >> as eth0.ip-address, eth0.prefix, eth0.gateway, which could easily be mapped >> using DG logic to the proper value, e.g. eth0. means I’m expecting the >> capability resolving eth0 to provide all the values for the ip-address, >> prefix, gateway. >> >> My goal is not necessary to jump to solution, but mainly to expose current >> limitation so we can think of the best solution to address it. >> >> Alexis >> >> >> >> On Aug 30, 2018, at 10:34 AM, FREEMAN, BRIAN D <[email protected]> wrote: >> >> >> >> Alexis, >> >> I think I am talking about the SO to SDNC interface and you are talking >> about the SDNC to Capability Resolution sub-interface inside SDNC. >> >> In the end , SO should get back a single response with an array of all the >> HEAT/TOSCA/ARM environment parameters needed or >> if this is config generation inside SDNC , the result is a payload configlet >> for SDNC to use internally that has all the parameters needed. >> >> Your valid concern is how to avoid a query per parameter inside SDNC and I >> agree its sub-optimal. >> >> It seems like there is still a mapping required inside SDNC that can make >> set of parameters to a capability resolution query – this seems like it >> would be a template language construct in the template parsing since the >> template designer would need to know that this set of parameters (ipadress, >> gateway, prefix) are the result of the same query to capability resolution. >> >> Am I in sync now ? >> >> Brian >> >> >> >> From: [email protected] <[email protected]> On Behalf Of >> Alexis de Talhouet >> Sent: Thursday, August 30, 2018 7:54 AM >> To: [email protected]; MALAKOV, YURIY <[email protected]> >> Cc: TIMONEY, DAN <[email protected]>; CHEUNG, PAT <[email protected]>; SINGH, AJAY >> <[email protected]>; ALBETAR, AMMAR <[email protected]> >> Subject: Re: [onap-discuss] [CDS][SDNC] - Modification of >> GENERIC-RESOURCE-API to support capability with multiple return values >> >> Yuriy, I added inline answers. >> >> On Aug 29, 2018, at 4:55 PM, MALAKOV, YURIY <[email protected]> wrote: >> >> Alexi, >> Excellent question. Your absolutely right that we need a generic solution to >> handle such use cases. >> >> The question becomes if the capability mS/Rest API always returns a simple >> response structure that fits the proposed schema or nested response >> structured. If you have nested response structured then we would need to >> modify the Yang schema to handle such scenario. >> >> AdT: if the plugin response is a complex structure, it would be its job to >> unmarshall such structure to set properly the param in the context for which >> the capability is called. As we are supposed to know in advance what are the >> params we want to resolve. >> >> >> >> >> Once the data is then persisted in the MD-SAL, how to we utilize for other >> cloud param resolution? >> >> It would be good to discuss this on the SDN-C/CCSDK forum to come up with a >> generic strategy for cloud param resolution that can handle complex nested >> output structure for resource assignment resolution. >> >> >> AdT: agree. Is there an agenda for next meeting where we can add bullet >> point? >> >> >> >> NOTE: From external client perspective, MSO is only extracting for >> name/value in params block for cloud param resource when the >> sdnc_generated_cloud_resources is set to true. >> >> list param { >> key "name"; >> leaf name { >> type string; >> } >> leaf value { >> type string; >> } >> >> >> From: Alexis de Talhouët [mailto:[email protected]] >> Sent: Wednesday, August 29, 2018 2:11 PM >> To: onap-discuss <[email protected]> >> Cc: TIMONEY, DAN <[email protected]>; MALAKOV, YURIY <[email protected]> >> Subject: [CDS][SDNC] - Modification of GENERIC-RESOURCE-API to support >> capability with multiple return values >> >> Team, >> >> For the self serve initiative, resolution from a specific capability might >> produce more than one value. >> If we take the example of assigning an IP address, the capability could >> return three values: the ip address, the prefix, and the gateway. >> Current modelling doesn’t enable us to generically say a particular value is >> to be set for a given param, as the model allows us to only set one param >> for a request. >> But in this example, I’d like to have one resolution request providing >> values to 3 params. >> >> Hence, current modelling of the `param` grouping might not solve all use >> cases. To that, I’m proposing to change the generic-resource-api.yang >> schema, and have a list of param that can be resolved by a single capability >> call. >> >> Currently, we have: >> grouping param { >> list param { >> key "name"; >> leaf name { >> type string; >> } >> leaf value { >> type string; >> } >> container resource-resolution-data { >> list resource-key { >> key "name"; >> leaf name { >> type string; >> } >> leaf value { >> type string; >> } >> } >> leaf status { >> description "SUCCESS, FAILED, or PENDING - RA returned data >> as capability"; >> type string; >> } >> leaf capability-name { >> description "Resource assignment resolution Capability name"; >> type string; >> } >> } >> } >> } >> >> What I’m proposing is the addition of the yellow portion: >> grouping param { >> list param { >> key "id"; >> leaf id { >> type string; >> } >> list outcome { >> key "name"; >> leaf name { >> type string; >> } >> leaf value { >> type string; >> } >> } >> container resource-resolution-data { >> list resource-key { >> key "name"; >> leaf name { >> type string; >> } >> leaf value { >> type string; >> } >> } >> leaf status { >> description "SUCCESS, FAILED, or PENDING - RA returned data >> as capability"; >> type string; >> } >> leaf capability-name { >> description "Resource assignment resolution Capability name"; >> type string; >> } >> } >> } >> >> That way, the list param.[$i].outcome could be passed by the DG to the >> capability that will be able to set variable in the SvcLogicContext for each >> of those outcome, so DG can then set them accordingly in the MDSAL. >> >> Other option is to have param[$i].name and param[$i].value be JSON element >> boxed in a string, but this is somewhat not very nice. >> >> What are your thoughts? We don’t have any use case in ONAP to support this >> modification, but I’m certain it will arise soon. >> >> Also, I’m not fully aware of how this information is used later on, hence >> what/who could be impacted by such changement. >> >> Alexis >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12168): https://lists.onap.org/g/onap-discuss/message/12168 Mute This Topic: https://lists.onap.org/mt/25076228/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
