Re: [onap-discuss] [modeling][cloud infrastructure]

[GUPTA, ARUN]

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 ; denghui (L) 
Cc: onap-discuss@lists.onap.org; onap-tsc ; GUPTA, 
ARUN 
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: 
onap-discuss-boun...@lists.onap.org<mailto: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) mailto:denghu...@huawei.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; onap-tsc 
mailto:onap-...@lists.onap.org>>; GUPTA, ARUN 
mailto: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]htt

[onap-discuss] [modeling][cloud infrastructure]

[GUPTA, ARUN]

The Wiki pages for Cloud Infrastructure Modeling in general:
https://wiki.onap.org/pages/viewpage.action?pageId=33065694
and for Cloud Aggregation Classes:
https://wiki.onap.org/display/DW/Cloud+Infrastructure+Aggregate+Representation+Classes

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





___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling][cloud infrastructure]

[GUPTA, ARUN]

The Wiki pages for Cloud Infrastructure Modeling in general:
https://wiki.onap.org/pages/viewpage.action?pageId=33065694
and for Cloud Aggregation Classes:
https://wiki.onap.org/display/DW/Cloud+Infrastructure+Aggregate+Representation+Classes

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





___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss