We re not trying to fulfill this requirement; although we are very aware of it. It is planned for Dublin, and won’t get in Casablanca; this is not the intention. We’re not either changing any of the existing behaviour. I’m not proposing any solution here, simply asking for an API waiver as we need to add a field in GR-API yang to get rid of the hard coded cloud owner in the new SO BB. The solution has been there before, it’s just lack of time before API freeze, and in this matter, introducing a regression.
Background: SO and SDNC added respectively new Building Blocks and support for GR-API, in order to avoir having to perform the manual preload step. With these new flows, at assignment stage, all the required ressources would get resolved by SDNC and stored in SDNC GR-API, so at creation stage, all SO has to do is query SDNC to gets the resources to use, and proceed with creation. What was uncover late is SO new BBs are using a hard coded cloud owner. The change is simply to allow having that cloud owner configurable. It is a small/quick fix in order to provide somewhat of a feature parity between former SO flow and new SO flows. I’m asking the TSC for an API waiver as we're pass API freeze and this is an API change, in some ways. If you want to discuss more in detail that functionality, I’ll be happy to explain over a meeting. My intention is to have a quick turnaround on the API change waiver request. I hope TSC will be able to see the urgency in that matter, given RC0, so we don’t debate too much on a requirement, as as stated before, we’re not trying to fulfil any; simply to fix a regression. Thanks, Alexis > On Oct 11, 2018, at 9:04 PM, Yang Bin <bin.y...@windriver.com> wrote: > > Hi Alexis, Dan, > > I am not sure if you are aware the ONAP functional requirement > about the “Centralized Representation and Consistent Identification of Cloud > Regions In ONAP” > https://wiki.onap.org/display/DW/Centralized+Representation+and+Consistent+Identification+of+Cloud+Regions+In+ONAP > > The functional requirement consists of 2 important changes: > 1, remove any hardcoded/redundant representation of a single cloud region, > the hard-coded cloud-sites in SO configuration file is exactly what is > targeting to be refactored. Now this part is on track of pairwise testing > between SO/MultiCloud . > 2, apply the usage of ID of a cloud region in a consistent way , the > agreement is that the composite keys: {cloud-owner}/{cloud-region-id} will be > applied whenever ONAP component wants to refer to a cloud region. This part > requires the API changes between VID/SO/SDNC and other related projects. It > is a stretch goal in Casablanca, perhaps we can get it done in Dublin > Release. > > I do believe both of 2 changes above might be related to your > proposal. I would like to discuss a little bit about the issue and your > proposal so that maybe we can come up with more comprehensive/consistent > solution to get things (API changes) done at one time. > > If you don’t mind, we can start with several questions: > 1, why should the Cloud-Owner be provisioned to SDNC with > REST-API? > I guess your proposal is to provision the “Cloud Owner” instead of having it > being hard-coded . I agree with you that it should not be hard-coded, but why > should the Cloud-Owner be provisioned to SDNC with REST-API? > IMHO, “Cloud-Owner” (and the cloud-region-id ) should be selected either by > user via VID portal or by OOF according to policy. In that case, the ID of > the selected cloud region ({cloud-owner}/{cloud-region-id} ) should be passed > to SO/SDNC/etc. through rest API. > > 2, Will SDNC use the ID of the selected cloud region to retrieve information > from AAI? > This question is to help me understand what the interactions > are between SDNC and AAI > > 3, Will SDNC use the ID of the selected cloud region to retrieve information > from underlying VIM/Cloud instance (e.g. OpenStack instance)? > This question would help me understand if there is interaction > between SDNC and underlying VIM/Cloud instance > > Thanks > > Best Regards, > Bin Yang, Solution Engineering Team, Wind River > ONAP Multi-VIM/Cloud PTL > Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189 > Skype: yangbincs993 > > From: onap-tsc@lists.onap.org [mailto:onap-tsc@lists.onap.org] On Behalf Of > Alexis de Talhouet > Sent: Friday, October 12, 2018 4:59 AM > To: onap-tsc; onap-discuss > Cc: Seshu m; TIMONEY, DAN > Subject: [onap-tsc] [TSC] Request API change waiver between SO and SDNC > > Hello TSC, > > As discussed during today’s meeting, an issue has been identified in the new > SO building block, introducing a regression in term of functionality from > previous release. > PTLs from both projects acknowledge and agree with the required changes. > > Expected behaviour: > Have the cloud owner / cloud region being retrievable from static > configuration file. > > Current behaviour: > Cloud owner is hardcoded in the code, with no way to change it using config > file. > > API change requested: > SDN-C: GENERIC-RESOURCE-API.yang > > Impact: > This API change will allow SO to resolve the cloud owner from the config file > (similar to what we had in previous release), and to be able to use it with > the GR-API. > > Patches: > SO: > 1. Use a property instead of hard coded value. (TBD) > 2. Push the changeset to allow it to be set on the north-bound > api. (TBD) > SDNC: > 1 Add cloud-owner definition: > .https://gerrit.onap.org/r/#/c/67413/ > > Regards, > Alexis > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3884): https://lists.onap.org/g/onap-tsc/message/3884 Mute This Topic: https://lists.onap.org/mt/27260030/21656 Group Owner: onap-tsc+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
