To continue the thread:
1. The purpose of the cloud aggregation concepts is to describe groupings of cloud resources – groupings that partition the resources (mutually exclusive group membership), and groupings that are not mutually exclusive. 2. It turns out that in the R2 VNF Design time model, we have made some commitment to a set of groupings: https://wiki.onap.org/display/DW/Design+Time+Model+Clean+Version#DesignTimeModelCleanVersion-Class:AffinityOrAntiAffinityGroup AffinityOrAntiAffinityGroup.scope takes on the values "NFVI-PoP", "Zone", "ZoneGroup", "NFVI-node". (These are values from the ETSI NFV Information Model). Zone == ResourceZone == proposed “Resource Cluster” ZoneGroup == collection of Zones ~ “Resource Cluster Group”. NFVI-PoP == physical data center end point (NFVI-node is a physical server, a compute node). 3. It is true that OpenStack doesn’t provide a “ZoneGroup” concept. If we go Cloud Native however, cloud providers have the idea of a collection of virtualized servers within which one manages one’s containers (e.g., AWS Fargate, Azure Service Fabric), and this collection can be organized hierarchically. E.g., failure domains in Azure Service Fabric: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-resource-manager-cluster-description One criticism of the modest proposal in the cloud aggregation concepts is that it does not allow for this kind of hierarchy of groups. On the other hand, the ZoneGroup concept may not be very useful in a VNFs-run-only-as-VMs environment. 4. Perhaps we can make useful the distinction between Information Model and Data Model. The Data Model is what is implemented or what is about to be implemented; while the Information Model is what attempts to be a complete, futureproof, standards-body-compliant description of the domain of interest; in which case, the data model for Casablanca should focus on what amendments, if any, that are needed to "NFVI-PoP", "Zone", "ZoneGroup", "NFVI-node" to support Casablanca use cases; and realizing these in the various public clouds and owner-operated clouds of interest. -Arun From: HU, BIN Sent: Monday, June 04, 2018 10:30 AM To: Zhipeng Huang <[email protected]>; denghui (L) <[email protected]> Cc: [email protected]; onap-tsc <[email protected]>; GUPTA, ARUN <[email protected]> Subject: RE: [onap-discuss] [modeling][cloud infrastructure] 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Zhipeng Huang Sent: Monday, June 04, 2018 1:10 AM To: denghui (L) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; onap-tsc <[email protected]<mailto:[email protected]>>; GUPTA, ARUN <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of GUPTA, ARUN Sent: Tuesday, May 22, 2018 11:20 PM To: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: [email protected]<mailto:[email protected]> Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
