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] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> On Behalf > Of Alexis de Talhouet > Sent: Thursday, August 30, 2018 7:54 AM > To: [email protected] <mailto:[email protected]>; > MALAKOV, YURIY <[email protected] <mailto:[email protected]>> > Cc: TIMONEY, DAN <[email protected] <mailto:[email protected]>>; CHEUNG, PAT > <[email protected] <mailto:[email protected]>>; SINGH, AJAY <[email protected] > <mailto:[email protected]>>; ALBETAR, AMMAR <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>] > Sent: Wednesday, August 29, 2018 2:11 PM > To: onap-discuss <[email protected] > <mailto:[email protected]>> > Cc: TIMONEY, DAN <[email protected] <mailto:[email protected]>>; MALAKOV, YURIY > <[email protected] <mailto:[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 (#12154): https://lists.onap.org/g/onap-discuss/message/12154 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]] -=-=-=-=-=-=-=-=-=-=-=-
