Howard, Thank you for your questions and concerns.
Would you mind proposing an improvement proposal to address your concerns? For example, - A model representing a relationship of abstraction rather than aggregation (to address your first concern)? - More specifically, a model to improve RCGC (or alternative of RCGC) to address your exemplary concern? - An improvement model (or an alternative model) of resource slices to address your second concern? Look forward to your proposal of improvement. Thanks Bin From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Zhipeng Huang Sent: Monday, June 04, 2018 1:10 AM To: denghui (L) <denghu...@huawei.com> Cc: onap-discuss@lists.onap.org; onap-tsc <onap-...@lists.onap.org>; GUPTA, ARUN <ag7...@att.com> Subject: Re: [onap-discuss] [modeling][cloud infrastructure] Hi Arun and all, Sorry for the late response, I just want to re-state my concern during the conf call earlier on the mailing-list. My first concern is that for the data modeling, we should adopt a common denominator of different VIM implementations. This means each concept defined in the data model here should be able to correctly mapped to various VIM implementations within scope. Moreover, a good data model should represent a relationship of abstraction rather than aggregation. Take Resource Cluster Group Class for example, it merely represents an arbitrary aggregation of the Resource Cluster Group which means this concept does not provide any abstraction over underlying resource concept. Another problem is that only VMware implementation has a nicely mapped corresponding concept to RCGC, whereas in OpenStack it is just obscurely mapped to "a set of host-aggregates". And if you remove the RCG point in the diagram provided in [0], you can see that no major connection will be disrupted, which also proves as a leaf node it is not a necessary one. RCGC is something I would recommend we avoid for the data modeling of multicloud. Secondly, I'm concerned with the concept of resource slice. Again it seems very arbitrarily crafted as a subset of resource (which again I fail to see an abstraction relationship but an aggregation one). It would be great if this concept is necessary then we have a very good detailed explanation of why we need it. [0]https://wiki.onap.org/display/DW/Cloud+Infrastructure+Aggregate+Representation+Classes<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Cloud-2BInfrastructure-2BAggregate-2BRepresentation-2BClasses&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE&s=dVt4smJlK6WgC6oLSpR9WJ_voytVjCOJBx2YuL4r33s&e=> On Wed, May 23, 2018 at 10:26 AM, denghui (L) <denghu...@huawei.com<mailto:denghu...@huawei.com>> wrote: Hello modelers, We are hoping that people could raise the discussion point before next Tuesday modeling call in this list or wiki page, we will limit one point discussion time during our next call. Thanks a lot DENG Hui From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of GUPTA, ARUN Sent: Tuesday, May 22, 2018 11:20 PM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] [modeling][cloud infrastructure] The Wiki pages for Cloud Infrastructure Modeling in general: https://wiki.onap.org/pages/viewpage.action?pageId=33065694<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D33065694&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE&s=JG1DWSVpQE8Dn473NJM79sLHMYu_v5IgC6uxLYpmWuk&e=> and for Cloud Aggregation Classes: https://wiki.onap.org/display/DW/Cloud+Infrastructure+Aggregate+Representation+Classes<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Cloud-2BInfrastructure-2BAggregate-2BRepresentation-2BClasses&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE&s=dVt4smJlK6WgC6oLSpR9WJ_voytVjCOJBx2YuL4r33s&e=> The presentation used in today’s (Tuesday May 22) Modeling Committee call is on the second page. -Arun Arun Gupta Lead Member of Technical Staff Domain 2 Architecture and Planning 200 S Laurel Ave – Bldg B, B5-3Z09 Middletown, NJ 07748 P: 732 420 6597 arungu...@att.com<mailto:arungu...@att.com> _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> https://lists.onap.org/mailman/listinfo/onap-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE&s=EBYCDHLryKXJAnkp9P55NK5ynmUoqUe9Sqf_QeREc0M&e=> -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com<mailto:huangzhip...@huawei.com> Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu<mailto:zhipe...@uci.edu> Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
