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: <[email protected]> on behalf of "FREEMAN, BRIAN D" <[email protected]> Reply-To: "[email protected]" <[email protected]>, "FREEMAN, BRIAN D" <[email protected]> Date: Wednesday, August 29, 2018 at 5:34 PM To: "[email protected]" <[email protected]>, "MALAKOV, YURIY" <[email protected]>, Alexis de Talhouët <[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. 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]<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 (#12142): https://lists.onap.org/g/onap-discuss/message/12142 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]] -=-=-=-=-=-=-=-=-=-=-=-
