Re: [onap-discuss] M3 Beijing Functionality Freeze is coming

[Gildas Lanilis]

Yes Srini. Please have your project on Chris'list for ARC review on Tuesday.

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: Addepalli, Srinivasa R [mailto:srinivasa.r.addepa...@intel.com]
Sent: Friday, March 02, 2018 5:03 PM
To: Gildas Lanilis ; onap-rele...@lists.onap.org
Cc: onap-discuss@lists.onap.org; onap-...@lists.onap.org
Subject: RE: M3 Beijing Functionality Freeze is coming

Hi Gildas,

A question on this
"I would like to highlight the most important item is related to this question 
"Has the Project team reviewed the APIs with the Architecture Committee (ARC)?" 
"

Should this review with ARC be expected to be done before 8th?

Thanks
Srini


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Gildas Lanilis
Sent: Friday, March 2, 2018 4:45 PM
To: onap-rele...@lists.onap.org
Cc: onap-discuss@lists.onap.org; 
onap-...@lists.onap.org
Subject: [onap-tsc] M3 Beijing Functionality Freeze is coming

Dear PTLs,

According to the Beijing Release 
Planning
 Thursday, March 8 is the Beijing M3 API 
Freeze.
It is expected that PTL fills out a copy of the M3 API Freeze 
Checklist
 in their project workspace.

I would like to highlight the most important item is related to this question 
"Has the Project team reviewed the APIs with the Architecture Committee (ARC)?"
As Chris suggested in former PTL and TSC meetings, bring your design-API 
related work to ARC meeting for review.

As you progress in this exercise, I will review the M3 artifacts and provide a 
summary to the community during TSC Meeting on Thursday, March 8. If you have 
any questions or concerns please reach out, I will be glad to help.

Thanks,
Gildas

[HuaweiLogowithName]
Gildas Lanilis
ONAP Release Manager
Santa Clara CA, USA
gildas.lani...@huawei.com
Mobile: 1 415 238 6287

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

Re: [onap-discuss] M3 Beijing Functionality Freeze is coming

[Addepalli, Srinivasa R]

Hi Gildas,

A question on this
"I would like to highlight the most important item is related to this question 
"Has the Project team reviewed the APIs with the Architecture Committee (ARC)?" 
"

Should this review with ARC be expected to be done before 8th?

Thanks
Srini


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Gildas Lanilis
Sent: Friday, March 2, 2018 4:45 PM
To: onap-rele...@lists.onap.org
Cc: onap-discuss@lists.onap.org; onap-...@lists.onap.org
Subject: [onap-tsc] M3 Beijing Functionality Freeze is coming

Dear PTLs,

According to the Beijing Release 
Planning
 Thursday, March 8 is the Beijing M3 API 
Freeze.
It is expected that PTL fills out a copy of the M3 API Freeze 
Checklist
 in their project workspace.

I would like to highlight the most important item is related to this question 
"Has the Project team reviewed the APIs with the Architecture Committee (ARC)?"
As Chris suggested in former PTL and TSC meetings, bring your design-API 
related work to ARC meeting for review.

As you progress in this exercise, I will review the M3 artifacts and provide a 
summary to the community during TSC Meeting on Thursday, March 8. If you have 
any questions or concerns please reach out, I will be glad to help.

Thanks,
Gildas

[HuaweiLogowithName]
Gildas Lanilis
ONAP Release Manager
Santa Clara CA, USA
gildas.lani...@huawei.com
Mobile: 1 415 238 6287

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

[onap-discuss] M3 Beijing Functionality Freeze is coming

[Gildas Lanilis]

Dear PTLs,

According to the Beijing Release 
Planning
 Thursday, March 8 is the Beijing M3 API 
Freeze.
It is expected that PTL fills out a copy of the M3 API Freeze 
Checklist
 in their project workspace.

I would like to highlight the most important item is related to this question 
"Has the Project team reviewed the APIs with the Architecture Committee (ARC)?"
As Chris suggested in former PTL and TSC meetings, bring your design-API 
related work to ARC meeting for review.

As you progress in this exercise, I will review the M3 artifacts and provide a 
summary to the community during TSC Meeting on Thursday, March 8. If you have 
any questions or concerns please reach out, I will be glad to help.

Thanks,
Gildas

[HuaweiLogowithName]
Gildas Lanilis
ONAP Release Manager
Santa Clara CA, USA
gildas.lani...@huawei.com
Mobile: 1 415 238 6287

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

[onap-discuss] [modeling] Data model mapping using SOL001

[jessie jewitt]

This message is particularly directed to Anatoly, Alex, and Thinh, as we
have an action item to map ONAP IM to DM. If one of you could respond, I'd
appreciate it.

My understanding is that SOL001 is mapping the VNFD model to TOSCA. They
indicate they are mapping the  ETSI NFV elements listed below into TOSCA
types (page 12).

I'm not clear why they chose the elements they did, as they don't all
correspond to the VNFD model which is defined in the ETSI
"VnfTemplateModule" of the model.

Also, the actual ETSI elements named do not correspond to exactly what is
defined in the model (they probably just got sloppy, but they should pay
attention to detail).

Here's the list of the currently defined elements that they map
1. VNF   -   Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of
the model. Also, the element is called Vnf and not VNF.
2. VDU   -   OK, but it should be Vdu, not VDU.
3. Cpd  -Maybe ok? It is defined in the CommonTemplateModule as an
abstract class. You don't instantiate abstract classes, so you will never
have an instance. Do you have TOSCA types that represent abstract classes?
Also, they don't map other abstract classes such as VirtualLinkDesc, so why
map this one?
4. VduCpd  - OK. This would contain all the attributes in Cpd, so again I'm
not sure why you need  Cpd.
5. VnfVirtualLinkDesc - OK
6. VnfExtCpd - OK
7. Virtual Storage - Shouldn't this be VirtualStorageDesc?
8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to
distinguish it from the VirtualCompute class.
9. Software Image -  Shouldn't this be SwImageDesc? Particularly to
distinguish it from SwImage.
10. Deployment Flavour - Shouldn't this be VnfDf?
11. Scaling Aspect - They should at least give the correct element name of
ScalingAspect.
12. Element Group - I assume they mean VnfdElementGroup? They should use
the correct name.
13. Instantiation Level -  OK, but they should give the correct name
InstantiationLevel.

The names used in the Tosca types should be an exact reflection of the ETSI
NFV element names as defined above. This is not always the case. For
example, they use "VirtualCompute" instead of "VirtualComputeDesc". As we
made changes in ONAP to ETSI class names, are we considering  making
changes to TOSCA type names to ensure adherence to the actual element
names. Or do we want to change them to match ONAP names? For example,
should  tosca.nodes.nfv.Cpd be tosca.nodes.nfv.CPDesc?

Also, they don't appear to map the all the classes that are defined in the
VNFD model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc.
Why?

Thank you for your help,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] SDC- local development - how to?

[Morales, Victor]

Hey Marcin,

We tried to collect most of the instructions (clone and compile, install 
dependencies, build docker images, etc.) into the vagrant-onap script [1].  
This is its documentation [2], but it’s not covering the configuration and 
installation of the IDE, I suggest to install it manually and use the opt 
folder given that it’s sharing the source code between host and guest computers.

Regards/Saludos
Victor Morales

[1] 
https://github.com/onap/integration/blob/master/bootstrap/vagrant-onap/lib/sdc
[2] 
http://onap.readthedocs.io/en/amsterdam/submodules/integration.git/bootstrap/vagrant-onap/doc/source/index.html


From:  on behalf of "Migdal, Marcin (Nokia 
- PL/Wroclaw)" 
Date: Thursday, March 1, 2018 at 12:37 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] SDC- local development - how to?

Hello,

Is there any instruction how to setup SDC for development in any IDE?


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

Re: [onap-discuss] 答复: UUI health-check amsterdam

[Ptacek Michal]

Hi,

well, the easier part would be if /iui/usecase-ui/ is the correct one,
so we can just modify robot healthcheck test and it will pass

please advise,
Michal

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of shentao
Sent: Friday, March 2, 2018 11:41 AM
To: 'Alexis de Talhouët' ; 'onap-discuss' 

Subject: [onap-discuss] 答复: UUI health-check amsterdam

Hi, Alexis

Sorry for my late reply. I’ve just returned from my holiday.
The right URI is “/iui/usecaseui/” because UUI has been registered in MSB by 
this path.

Best regards,
Tao

发件人: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] 代表 Alexis de Talhou?t
发送时间: 2018年3月1日 21:36
收件人: onap-discuss
主题: Re: [onap-discuss] UUI health-check amsterdam

Hello,

Any news on the same? This is giving bad publicity to UUI that health-check is 
failing in OOM. Please help us address this.

Alexis

On Feb 20, 2018, at 12:47 PM, Alexis de Talhouët 
mailto:adetalhoue...@gmail.com>> wrote:

Hi UUI experts,

UUI health-check has been failing on amsterdam for a few weeks now, I could 
find that patch has changed the uri to use https://gerrit.onap.org/r/#/c/28431/
Amsterdam is giving 200 OK for /iui/usecase-ui/ and 502 for /iui/usecaseui/ so 
since this patch came in, it’s failing.
What should be the URI to use for amsterdam for this health-check ?

Alexis

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

[onap-discuss] 答复: UUI health-check amsterdam

[shentao]

Hi, Alexis

 

Sorry for my late reply. I’ve just returned from my holiday.

The right URI is “/iui/usecaseui/” because UUI has been registered in MSB by 
this path.

 

Best regards,

Tao

 

发件人: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] 代表 Alexis de Talhou?t
发送时间: 2018年3月1日 21:36
收件人: onap-discuss
主题: Re: [onap-discuss] UUI health-check amsterdam

 

Hello,

 

Any news on the same? This is giving bad publicity to UUI that health-check is 
failing in OOM. Please help us address this.

 

Alexis





On Feb 20, 2018, at 12:47 PM, Alexis de Talhouët  
wrote:

 

Hi UUI experts,

 

UUI health-check has been failing on amsterdam for a few weeks now, I could 
find that patch has changed the uri to use https://gerrit.onap.org/r/#/c/28431/

Amsterdam is giving 200 OK for /iui/usecase-ui/ and 502 for /iui/usecaseui/ so 
since this patch came in, it’s failing.

What should be the URI to use for amsterdam for this health-check ?

 

Alexis

 

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