Steve, Those params would remain the params to fill in the HEAT, no transformation would be required. What would be required is an extra lookup step. BTW, if I understood correctly, the transformation is currently hardcoded in the DG flows... this is what I’m trying to address. But of course I don’t want to push this transformation to SO. I am trying to see if there is a more generic way so DG flow remain agnostic.
Alexis > On Aug 30, 2018, at 7:37 AM, Steve Smokowski <ss8...@att.com> wrote: > > Heat would require what Brian has pointed out here. The design you proposed > SO would have to transform your data into heat name/value params, which is > what the design is attempting to avoid. > > Thanks > > -Steve > > > From: <onap-discuss@lists.onap.org> on behalf of "FREEMAN, BRIAN D" > <bf1...@att.com> > Reply-To: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, > "FREEMAN, BRIAN D" <bf1...@att.com> > Date: Wednesday, August 29, 2018 at 5:34 PM > To: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, "MALAKOV, > YURIY" <ym9...@att.com>, Alexis de Talhouët <adetalhoue...@gmail.com> > Cc: "TIMONEY, DAN" <dt5...@att.com>, "CHEUNG, PAT" <kc1...@att.com>, "SINGH, > AJAY" <as3...@att.com>, "ALBETAR, AMMAR" <amm...@amdocs.com> > 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. > > > 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: onap-discuss@lists.onap.org <onap-discuss@lists.onap.org> On Behalf Of > MALAKOV, YURIY > Sent: Wednesday, August 29, 2018 4:56 PM > To: Alexis de Talhouët <adetalhoue...@gmail.com>; onap-discuss > <onap-discuss@lists.onap.org> > Cc: TIMONEY, DAN <dt5...@att.com>; CHEUNG, PAT <kc1...@att.com>; SINGH, AJAY > <as3...@att.com>; ALBETAR, AMMAR <amm...@amdocs.com> > 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:adetalhoue...@gmail.com] > Sent: Wednesday, August 29, 2018 2:11 PM > To: onap-discuss <onap-discuss@lists.onap.org> > Cc: TIMONEY, DAN <dt5...@att.com>; MALAKOV, YURIY <ym9...@att.com> > 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 (#12145): https://lists.onap.org/g/onap-discuss/message/12145 Mute This Topic: https://lists.onap.org/mt/25076228/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
