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] > <mailto:[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 (#12156): https://lists.onap.org/g/onap-discuss/message/12156 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]] -=-=-=-=-=-=-=-=-=-=-=-
