Brian, Based on the schema, one resource-resolution-data can only set one value for a param. So if there is three parameters to assign, but there is only one resource-resolution-data request needed for them all, current model doesn’t work, right?
What you might be saying is, let’s make three distinct resolution requests to our capability, which is exactly what I don’t want, as a call is sufficient to retrieve all the data I need. Have I explained it better? > On Aug 29, 2018, at 5:34 PM, FREEMAN, BRIAN D <[email protected]> wrote: > > Alexis, > > “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.” > > I’m not understanding the issue. Wouldn’t there be three parameters returned > ip_address, ip_prefix and ip_gateway. > > Param: [ > { “name”: “eth0.ip_address”, “value”: “10.0.0.2” }, > { “name”: “eth0.ip_prefix”, “value”: “10.0.0.0/24” } > { “name”: “eth0.ip_gateway”, “value”: “10.0.0.1” } > ] > > Where the name matches variables for the VSP heat template ? > > Am I just being dense ? which is likely :) > > Brian > > > > From: [email protected] <[email protected]> On Behalf Of > MALAKOV, YURIY > Sent: Wednesday, August 29, 2018 4:56 PM > To: Alexis de Talhouët <[email protected]>; onap-discuss > <[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 > > ***Security Advisory: This Message Originated Outside of AT&T *** > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > 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. > > 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. > > 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 (#12144): https://lists.onap.org/g/onap-discuss/message/12144 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]] -=-=-=-=-=-=-=-=-=-=-=-
