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