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

2018-06-05 Thread 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

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

2018-06-04 Thread HU, BIN 
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) 
Cc: onap-discuss@lists.onap.org; onap-tsc ; GUPTA, 
ARUN 
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=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6qPcDOqMgwf1K_r6YIIHhw=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE=dVt4smJlK6WgC6oLSpR9WJ_voytVjCOJBx2YuL4r33s=>



On Wed, May 23, 2018 at 10:26 AM, denghui (L) 
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=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6qPcDOqMgwf1K_r6YIIHhw=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE=JG1DWSVpQE8Dn473NJM79sLHMYu_v5IgC6uxLYpmWuk=>
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=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6qPcDOqMgwf1K_r6YIIHhw=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE=dVt4smJlK6WgC6oLSpR9WJ_voytVjCOJBx2YuL4r33s=>

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=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6qPcDOqMgwf1K_r6YIIHhw=b0jFV3nPUvLDLzEEih-QNhYmXbguWJjDy4qvLenPCxE=EBYCDHLryKXJAnkp9P55NK5ynmUoqUe9Sqf_QeREc0M=>



--
Zhipeng (Howard

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

2018-06-04 Thread Zhipeng Huang 
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



On Wed, May 23, 2018 at 10:26 AM, denghui (L)  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-bounces@
> lists.onap.org] *On Behalf Of *GUPTA, ARUN
> *Sent:* Tuesday, May 22, 2018 11:20 PM
> *To:* 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
>
> 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
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: 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
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

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

2018-05-22 Thread denghui (L) 
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] On Behalf Of GUPTA, ARUN
Sent: Tuesday, May 22, 2018 11:20 PM
To: 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
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<mailto: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]

2018-05-22 Thread 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]

2018-05-22 Thread 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