[onap-discuss] 答复: RE: [model][vCPE] Things missing in Onap Tosca DM?

[zhang.maopeng1]

Hi all






1. As I understand,  the heat template features vCPE used includes 
metadata,usedata,,, which are not included in the IM and DM now. 


2. pre-created network issue can be gotten as a input from TOSCA, but needs a 
properties of VL to represent it, such as description or a new properties.






BR


Maopeng



原始邮件



发件人：Lu,Lianhao 
收件人：Gaoweitao (Victor, MANO) onap-discuss@lists.onap.org 

抄送人：张茂鹏10030173;Vul, Alex Huang, Haibin 

日 期 ：2018年03月20日 11:45
主 题 ：RE: [model][vCPE] Things missing in Onap Tosca DM?




Hi Victor,


 


I’ve got some following-up  questions


 


1. SSH key pairs for VM


When  saying to use inject file to handle this, do you mean to inject ssh 
public key to ~/.ssh/authorized_keys file within in the VM?


 


2. cloudinit user scripts


I’ve looked at the inject file definition in IM. Here I’ve several questions 
about inject file:


-According to IM, the inject file property “Describes the information 
(e.g. URL) about the scripts, config drive metadata, etc. which can be used 
during Vdu booting process.” Do we need to specify the destination pathname 
within the VM  image for the injected scripts? Openstack needs this kind of 
information.


-vCPE usecase’s cloudinit scripts needs  to get some run-time dynamic 
properties & attributes of other VDUs, do we have a mechanism to pass those 
property/attribute values to the inject files?


-Why can’t we leverage the existing 
tosca.interfaces.node.lifecycle.Standard interface, just like  
https://github.com/openstack/tosca-parser/blob/master/toscaparser/tests/data/CSAR/tosca_elk/Definitions/tosca_elk.yaml#L79
  . This could solve the above run-time properties issue.


 


BR


-Lianhao


 



From: Gaoweitao (Victor, MANO) [mailto:victor@huawei.com] 
 Sent: Tuesday, March 20, 2018 9:48 AM
 To: Lu, Lianhao ; onap-discuss@lists.onap.org
 Cc: zhang.maope...@zte.com.cn; Vul, Alex ; Huang, Haibin 

 Subject: 答复: [model][vCPE] Things missing in Onap Tosca DM?




 


Hi  Lianhao,


   


Please see my comments inline.


 


BR


Victor


 



发件人: Lu, Lianhao [mailto:lianhao...@intel.com] 
 发送时间: 2018年3月19日 19:25
 收件人: onap-discuss@lists.onap.org
 抄送: zhang.maope...@zte.com.cn; Vul, Alex ;  Gaoweitao 
(Victor, MANO) ; Huang, Haibin 
 主题: [model][vCPE] Things missing in Onap Tosca DM?




 


Hi Guys,


 


I’m now looking at the vCPE usecase 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246168#UseCase:ResidentialBroadbandvCPE(Approved)-Description),
  and try to convert its heat 
template(https://git.onap.org/demo/tree/heat/vCPE) into latest onap Tosca  DM 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile  ). I 
found the following things in heat and can NOT find the corresponding mapping 
in the Tosca DM.


 


1. SSH key pairs for VM


Heat supports creating ssh keypair for VM to enable login with ssh 
public/private keys. However I could not find corresponding in latest onap 
tosca DM. Should we support this in tosca DM?


 


Victor: I think inject file could handle this.


 


2. cloudinit user scripts


In heat, vCPE uses cloudinit user script to executed within the VM after VM has 
been launched to configure the VNF softwares within the VM. However, in tosca 
DM, there is no direct mapping to such things in VDU. Should I use 
tosca.interfaces.node.lifecycle.Standard  interface instead or should we add 
new properties in VDU (see openstack tacker’s VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L239
 )? The new userdata should also support inputs like 
tosca.interfaces.node.lifecycle.Standard interface.


 


Victor: In general, we will use inject file handle this. You can refer here: 
https://wiki.onap.org/display/DW/Node+Type tosca.nodes.nfv.Vdu.Compute and IM 
inject file definition for more info : 
https://wiki.onap.org/display/DW/Design+Time+Model+Clean+Version#DesignTimeModelCleanVersion-Class:VDU/VDUDesc.


 


3. pre-created networks:


vCPE will use 2 pre-created networks which are created when ONAP itself is 
being deployed: onap_public_net is used to make VM be able to connect to 
internet, onap_private_net is the oam network which is used to make some of the 
vCPE vnf  talk to some onap component(e.g. dcae_collector). So this requires 
the VNF VM to be connected to a pre-created network. However in tosca DM, it 
seems that there is no way to specify a VDU created by tosca DM connecting to a 
pre-created network which is already  created during ONAP deployment using 
heat.  Should we add an property in tosca.nodes.nfv.VnfVirtualLink to indicate 
whether the network is pre-created or not?


Victor：Pre-created 

Re: [onap-discuss] [model][vCPE] Things missing in Onap Tosca DM?

[Lu, Lianhao]

Hi Victor,

I’ve got some following-up  questions

1. SSH key pairs for VM
When  saying to use inject file to handle this, do you mean to inject ssh 
public key to ~/.ssh/authorized_keys file within in the VM?

2. cloudinit user scripts
I’ve looked at the inject file definition in IM. Here I’ve several questions 
about inject file:

-According to IM, the inject file property “Describes the information 
(e.g. URL) about the scripts, config drive metadata, etc. which can be used 
during Vdu booting process.” Do we need to specify the destination pathname 
within the VM image for the injected scripts? Openstack needs this kind of 
information.

-vCPE usecase’s cloudinit scripts needs  to get some run-time dynamic 
properties & attributes of other VDUs, do we have a mechanism to pass those 
property/attribute values to the inject files?

-Why can’t we leverage the existing 
tosca.interfaces.node.lifecycle.Standard interface, just like  
https://github.com/openstack/tosca-parser/blob/master/toscaparser/tests/data/CSAR/tosca_elk/Definitions/tosca_elk.yaml#L79
 . This could solve the above run-time properties issue.

BR
-Lianhao

From: Gaoweitao (Victor, MANO) [mailto:victor@huawei.com]
Sent: Tuesday, March 20, 2018 9:48 AM
To: Lu, Lianhao ; onap-discuss@lists.onap.org
Cc: zhang.maope...@zte.com.cn; Vul, Alex ; Huang, Haibin 

Subject: 答复: [model][vCPE] Things missing in Onap Tosca DM?

Hi  Lianhao,

Please see my comments inline.

BR
Victor

发件人: Lu, Lianhao [mailto:lianhao...@intel.com]
发送时间: 2018年3月19日 19:25
收件人: onap-discuss@lists.onap.org
抄送: zhang.maope...@zte.com.cn; Vul, Alex 
>; Gaoweitao (Victor, MANO) 
>; Huang, Haibin 
>
主题: [model][vCPE] Things missing in Onap Tosca DM?

Hi Guys,

I’m now looking at the vCPE usecase 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246168#UseCase:ResidentialBroadbandvCPE(Approved)-Description),
 and try to convert its heat template(https://git.onap.org/demo/tree/heat/vCPE) 
into latest onap Tosca  DM 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile ). I 
found the following things in heat and can NOT find the corresponding mapping 
in the Tosca DM.

1. SSH key pairs for VM
Heat supports creating ssh keypair for VM to enable login with ssh 
public/private keys. However I could not find corresponding in latest onap 
tosca DM. Should we support this in tosca DM?

Victor: I think inject file could handle this.

2. cloudinit user scripts
In heat, vCPE uses cloudinit user script to executed within the VM after VM has 
been launched to configure the VNF softwares within the VM. However, in tosca 
DM, there is no direct mapping to such things in VDU. Should I use 
tosca.interfaces.node.lifecycle.Standard interface instead or should we add new 
properties in VDU (see openstack tacker’s VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L239
 )? The new userdata should also support inputs like 
tosca.interfaces.node.lifecycle.Standard interface.

Victor: In general, we will use inject file handle this. You can refer here: 
https://wiki.onap.org/display/DW/Node+Type tosca.nodes.nfv.Vdu.Compute and IM 
inject file definition for more info : 
https://wiki.onap.org/display/DW/Design+Time+Model+Clean+Version#DesignTimeModelCleanVersion-Class:VDU/VDUDesc.

3. pre-created networks:
vCPE will use 2 pre-created networks which are created when ONAP itself is 
being deployed: onap_public_net is used to make VM be able to connect to 
internet, onap_private_net is the oam network which is used to make some of the 
vCPE vnf talk to some onap component(e.g. dcae_collector). So this requires the 
VNF VM to be connected to a pre-created network. However in tosca DM, it seems 
that there is no way to specify a VDU created by tosca DM connecting to a 
pre-created network which is already created during ONAP deployment using heat. 
 Should we add an property in tosca.nodes.nfv.VnfVirtualLink to indicate 
whether the network is pre-created or not?
Victor：Pre-created network is no difference with new-create network, just use 
vnfvirtualLink describe the pre-created network, orchestrator could handle 
this（if network already created,  vm could re-use it.）

4. VM metadata
vCPE also uses VM metadata which is missing in Tosca DM’s VDU. Should we add 
this?( see openstack tacker’s VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L198
 )?
Victor: Lianhao, could u give more usage/info about the VDU/VM metadata, maybe 
we could 

Re: [onap-discuss] [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfigurationGuidelines

[fu.guangrong]

Okay. I'll reserve a meeting and send the zoom number to you later.






See you then.






Guangrong























Original Mail



Sender: JI,LUSHENG(LUSHENG) 
To: fuguangrong10144542;
CC: onap-discuss@lists.onap.org 
Date: 2018/03/20 10:08
Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice 
ScalingConfigurationGuidelines




I would prefer the first choice, 9:30-10:30 tomorrow evening.  Thanks,


Lusheng


 



From: "fu.guangr...@zte.com.cn" 
 Date: Monday, March 19, 2018 at 10:06 PM
 To: "JI, LUSHENG (LUSHENG)" 
 Cc: "onap-discuss@lists.onap.org" 
 Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration 
Guidelines



 


Lusheng,

 

9:30 AM - 11:30 AM, Mar. 21 (Beijing time, which is 9:30 PM - 11:30 PM, Mar. 
20) is feasible for me. Also, we could use the Holmes weekly call (starting 
from 8AM) on Thursday.

 

Which time slot is okay for you?

 

BR,

Guangrong

 

 

 

 


Original Mail



Sender: JI,LUSHENG(LUSHENG) 



To: fuguangrong10144542;



CC: onap-discuss@lists.onap.org 



Date: 2018/03/20 09:50



Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration 
Guidelines




Guangrong,


 


I think it is best to schedule a zoom call for explaining this, probably with 
some PoC demos.  We have couple of Kubernets clusters set up in the Pod25 
Integration lab. 


Please let me know what time would work for you.


 


Thanks,


Lusheng


 



From: "fu.guangr...@zte.com.cn" 
 Date: Monday, March 19, 2018 at 8:41 PM
 To: "JI, LUSHENG (LUSHENG)" 
 Cc: "onap-discuss@lists.onap.org" 
 Subject: [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration 
Guidelines



 

Hi Lusheng,

 

As we discussed last Thursday, could you please share some materials about the 
thoughts and configurations on DCAE microservice scaling with us?

 

Thanks,

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

Re: [onap-discuss] [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration Guidelines

[JI, LUSHENG (LUSHENG)]

I would prefer the first choice, 9:30-10:30 tomorrow evening.  Thanks,
Lusheng

From: "fu.guangr...@zte.com.cn" 
Date: Monday, March 19, 2018 at 10:06 PM
To: "JI, LUSHENG (LUSHENG)" 
Cc: "onap-discuss@lists.onap.org" 
Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration 
Guidelines


Lusheng,



9:30 AM - 11:30 AM, Mar. 21 (Beijing time, which is 9:30 PM - 11:30 PM, Mar. 
20) is feasible for me. Also, we could use the Holmes weekly call (starting 
from 8AM) on Thursday.



Which time slot is okay for you?



BR,

Guangrong








Original Mail
Sender: JI,LUSHENG(LUSHENG) 
To: fuguangrong10144542;
CC: onap-discuss@lists.onap.org 
Date: 2018/03/20 09:50
Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration 
Guidelines
Guangrong,

I think it is best to schedule a zoom call for explaining this, probably with 
some PoC demos.  We have couple of Kubernets clusters set up in the Pod25 
Integration lab.
Please let me know what time would work for you.

Thanks,
Lusheng

From: "fu.guangr...@zte.com.cn" 
Date: Monday, March 19, 2018 at 8:41 PM
To: "JI, LUSHENG (LUSHENG)" 
Cc: "onap-discuss@lists.onap.org" 
Subject: [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration 
Guidelines


Hi Lusheng,



As we discussed last Thursday, could you please share some materials about the 
thoughts and configurations on DCAE microservice scaling with us?



Thanks,

Guangrong








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

Re: [onap-discuss] [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration Guidelines

[fu.guangrong]

Lusheng,






9:30 AM - 11:30 AM, Mar. 21 (Beijing time, which is 9:30 PM - 11:30 PM, Mar. 
20) is feasible for me. Also, we could use the Holmes weekly call (starting 
from 8AM) on Thursday.






Which time slot is okay for you?






BR,


Guangrong



















Original Mail



Sender: JI,LUSHENG(LUSHENG) 
To: fuguangrong10144542;
CC: onap-discuss@lists.onap.org 
Date: 2018/03/20 09:50
Subject: Re: [dcae][dcaegen2] Ask for DCAE Microservice ScalingConfiguration 
Guidelines




Guangrong,


 


I think it is best to schedule a zoom call for explaining this, probably with 
some PoC demos.  We have couple of Kubernets clusters set up in the Pod25 
Integration lab. 


Please let me know what time would work for you.


 


Thanks,


Lusheng


 



From: "fu.guangr...@zte.com.cn" 
 Date: Monday, March 19, 2018 at 8:41 PM
 To: "JI, LUSHENG (LUSHENG)" 
 Cc: "onap-discuss@lists.onap.org" 
 Subject: [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration 
Guidelines



 

Hi Lusheng,

 

As we discussed last Thursday, could you please share some materials about the 
thoughts and configurations on DCAE microservice scaling with us?

 

Thanks,

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

Re: [onap-discuss] [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration Guidelines

[JI, LUSHENG (LUSHENG)]

Guangrong,

I think it is best to schedule a zoom call for explaining this, probably with 
some PoC demos.  We have couple of Kubernets clusters set up in the Pod25 
Integration lab.
Please let me know what time would work for you.

Thanks,
Lusheng

From: "fu.guangr...@zte.com.cn" 
Date: Monday, March 19, 2018 at 8:41 PM
To: "JI, LUSHENG (LUSHENG)" 
Cc: "onap-discuss@lists.onap.org" 
Subject: [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration 
Guidelines


Hi Lusheng,



As we discussed last Thursday, could you please share some materials about the 
thoughts and configurations on DCAE microservice scaling with us?



Thanks,

Guangrong






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

[onap-discuss] 答复: [model][vCPE] Things missing in Onap Tosca DM?

[Gaoweitao (Victor, MANO)]

Hi  Lianhao,

Please see my comments inline.

BR
Victor

发件人: Lu, Lianhao [mailto:lianhao...@intel.com]
发送时间: 2018年3月19日 19:25
收件人: onap-discuss@lists.onap.org
抄送: zhang.maope...@zte.com.cn; Vul, Alex ; Gaoweitao 
(Victor, MANO) ; Huang, Haibin 
主题: [model][vCPE] Things missing in Onap Tosca DM?

Hi Guys,

I’m now looking at the vCPE usecase 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246168#UseCase:ResidentialBroadbandvCPE(Approved)-Description),
 and try to convert its heat template(https://git.onap.org/demo/tree/heat/vCPE) 
into latest onap Tosca  DM 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile ). I 
found the following things in heat and can NOT find the corresponding mapping 
in the Tosca DM.

1. SSH key pairs for VM
Heat supports creating ssh keypair for VM to enable login with ssh 
public/private keys. However I could not find corresponding in latest onap 
tosca DM. Should we support this in tosca DM?

Victor: I think inject file could handle this.

2. cloudinit user scripts
In heat, vCPE uses cloudinit user script to executed within the VM after VM has 
been launched to configure the VNF softwares within the VM. However, in tosca 
DM, there is no direct mapping to such things in VDU. Should I use 
tosca.interfaces.node.lifecycle.Standard interface instead or should we add new 
properties in VDU (see openstack tacker’s VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L239
 )? The new userdata should also support inputs like 
tosca.interfaces.node.lifecycle.Standard interface.

Victor: In general, we will use inject file handle this. You can refer here: 
https://wiki.onap.org/display/DW/Node+Type tosca.nodes.nfv.Vdu.Compute and IM 
inject file definition for more info : 
https://wiki.onap.org/display/DW/Design+Time+Model+Clean+Version#DesignTimeModelCleanVersion-Class:VDU/VDUDesc.

3. pre-created networks:
vCPE will use 2 pre-created networks which are created when ONAP itself is 
being deployed: onap_public_net is used to make VM be able to connect to 
internet, onap_private_net is the oam network which is used to make some of the 
vCPE vnf talk to some onap component(e.g. dcae_collector). So this requires the 
VNF VM to be connected to a pre-created network. However in tosca DM, it seems 
that there is no way to specify a VDU created by tosca DM connecting to a 
pre-created network which is already created during ONAP deployment using heat. 
 Should we add an property in tosca.nodes.nfv.VnfVirtualLink to indicate 
whether the network is pre-created or not?
Victor：Pre-created network is no difference with new-create network, just use 
vnfvirtualLink describe the pre-created network, orchestrator could handle 
this（if network already created,  vm could re-use it.）

4. VM metadata
vCPE also uses VM metadata which is missing in Tosca DM’s VDU. Should we add 
this?( see openstack tacker’s VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L198
 )?
Victor: Lianhao, could u give more usage/info about the VDU/VM metadata, maybe 
we could use other properties or attributes instead.

Best Regards,
-Lianhao
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

[zhao.huabing]

Hi Parviz,


Is this scheduled for Monday? Sorry I missed it. Could we move it to the next 
call, is that this Friday?


Thanks,


Huabing







Original Mail



Sender: ParvizYegani 
To: zhaohuabing10201488;Christopher Donley(Chris) 

CC: onap-arch-tiger-t...@lists.onap.org 
onap-discuss@lists.onap.org 
Manoj K Nair 'Vul, 
Alex' 
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards 




Hi Huabing,


 


Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!


 


I added the following item to the agenda for today’s tiger team call:


-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.


Thank you


Parviz


 


---


PARVIZ YEGANI, PhD 
Chief SDN/NFV Architect


CTO Office, Cloud Network Solutions


 


FutureWei Technologies, Inc.


2330 Central Express Way


Santa Clara, CA 95050, USA


Phone: +1 (408) 330-4668


Mobile : +1 (408) 759-1973


parviz.yeg...@huawei.com 


 


 


 


From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn] 
 Sent: Wednesday, March 14, 2018 4:01 AM
 To: Parviz Yegani ; Christopher Donley (Chris) 

 Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
 Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards 


 

Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond

 

1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as 


· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)


· allowing free choice of development tech stack


· flexible route rules to enable traffic steering and canary release


· monitoring and tracing visibility


· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now. 

 

2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.

 

3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the  wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

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

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

[zhao.huabing]

Sure, I'll send out the slides later today before our call.











Original Mail



Sender: ParvizYegani 
To: zhaohuabing10201488;Christopher Donley(Chris) 

CC: onap-arch-tiger-t...@lists.onap.org 
onap-discuss@lists.onap.org 
Manoj K Nair 'Vul, 
Alex' 
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards 




Hi Huabing,


 


Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!


 


I added the following item to the agenda for today’s tiger team call:


-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.


Thank you


Parviz


 


---


PARVIZ YEGANI, PhD 
Chief SDN/NFV Architect


CTO Office, Cloud Network Solutions


 


FutureWei Technologies, Inc.


2330 Central Express Way


Santa Clara, CA 95050, USA


Phone: +1 (408) 330-4668


Mobile : +1 (408) 759-1973


parviz.yeg...@huawei.com 


 


 


 


From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn] 
 Sent: Wednesday, March 14, 2018 4:01 AM
 To: Parviz Yegani ; Christopher Donley (Chris) 

 Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
 Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards 


 

Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond

 

1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as 


· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)


· allowing free choice of development tech stack


· flexible route rules to enable traffic steering and canary release


· monitoring and tracing visibility


· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now. 

 

2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.

 

3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the  wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

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

[onap-discuss] [dcae][dcaegen2] Ask for DCAE Microservice Scaling Configuration Guidelines

[fu.guangrong]

Hi Lusheng,






As we discussed last Thursday, could you please share some materials about the 
thoughts and configurations on DCAE microservice scaling with us?






Thanks,


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

[onap-discuss] [OOM] Automated Azure full oneclick deployment of ONAP via ARM template with entrypoint script - POC

[Michael O'Brien]

Team,
A preliminary video for reference for the oneclick CD is posted to the wiki 
- specific to Microsoft Azure ARM for those curious or working with Azure.

Changes from the last one on the 12th  is I linked the scripts via the 
customscript resource extension in the arm template.
Note: the video is 35 min (paused in "no-action" times) - deployment is 
fully automated (run the Jenkins job - walk away for 70-90 min (depending on 
nexus3.onap.org throttling during the 20-40 min docker prepull)).

Flow
A Jenkins job (Azure infrastructure and vms run in the onap.cloud domain) 
runs the arm template that contains the entrypoint script that installs 
rancher/kubernetes then OOM via the cd.sh script all the way to using the ONAP 
portal.  Since most of these scripts are still in gerrit review - the system 
currently runs of curl downloads.
Branch is amsterdam
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure?preview=/20873997/27689096/20180319_azure_arm_to_onap_oneclick_via_entrypoint_sh.mp4
for
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure 
<https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure#ONAPonKubernetesonMicrosoftAzure-20180319:AmsterdamfullyautomatedARMtemplatetoONAPup>
https://jira.onap.org/browse/OOM-711 off my larger 
https://jira.onap.org/browse/OOM-710
The work consists of Azure specific templates in 711 with cloud-agnostic 
rancher (715) and cd.sh (716) parts.

   This is still a POC and will be mostly fine tuned/expanded (VN port 
lockdown, error handling, more parametrization, dual master/amst runs etc...) 
until this thu and later with presentation slated for ONS next Wed.

   There are recent issues with master that I ran into over the weekend - which 
look related to a Kubernetes 1.8.6 to 1.8.9 upgrade - thanks Gary for pointing 
that out - his CD system shows the same reverse-upgrade of Rancher 1.6.14 - 
that we are working on.
https://jira.onap.org/browse/OOM-813
https://lists.onap.org/pipermail/onap-discuss/2018-March/008706.html

   This particular video is for the amsterdam branch (but it takes the -b 
branch as a parameter and usually runs the same for master until last Friday).

   Thank you to Microsoft for the subscription access to 128G VMs
/michael


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] ONAP Jenkins build nodes renamed in preparation for common-packer

[Jessica Wagantall]

Dear ONAP team,

Please notice that, in preparation for common-packer, we have renamed all
our "*-basebuild-*" to "*-builder-*".
You can see the reference change here: https://gerrit.onap.org/r/#/c/36843/

Please use these node names for future JJB changes.

FYI, common-packer will allow us to have a better control and maintenance of
our Jenkins build instances by using all the latest provisioning scripts
that call
Ansible Galaxy to install all our packages. This upgrade is also in the
works and should
hopefully be ready soon. For more information:
https://github.com/lfit/releng-common-packer/

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

Re: [onap-discuss] New OOM deployment issues

[Michael O'Brien]

r comparison, another environment I 
deployed a week ago is on rancher/k8s:v1.8.5-rancher4 which was working fine.  
This is without me updating any rancher-specific configuration between the two, 
so maybe Rancher itself has changed?

Can you check your various OOM environments and see what versions of 
rancher/k8s they're on?

Thanks,
Gary


From: Michael O'Brien [mailto:frank.obr...@amdocs.com]
Sent: Monday, March 19, 2018 11:36 AM
To: Gary Wu <gary.i...@huawei.com<mailto:gary.i...@huawei.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: RE: New OOM deployment issues

Gary,
  Adding onap-discuss as we should always discuss ONAP health in public - as it 
may also catch the attention of anyone who did these changes.

  Yes when working on OOM-710 over the weekend noticed this issue specific to 
only my azure instances running in Ubuntu (I was working in master mainly so 
did not check amsterdam for a while - just checked and it is OK)  - Assumed it 
was my arm template as I am testing the entrypoint script in the script 
extension point.   I say this because I have always had this problem in Azure 
specific only to the Ubuntu user - since I started running as Ubuntu instead of 
just root (around Friday)

  Undercloud seems to be the issue here - mixed with some config in master 
(azure/openstack have issues, aws does not)
  Running the install in root did not have the issue on either AWS:EBS or Azure 
- before the 15th and only in azure/openstack:ubuntu:master after
  Running on AWS EBS also does not have the issue on Ubuntu or root

  So it looks like a permissions change on the config files sensitive to the 
file system.
  There were only 3 commits to master since the 15th so it does not look like 
any of those 3 would cause it
https://gerrit.onap.org/r/#/q/status:merged+oom

   Raised the following just for tracking - but until we go through the exact 
start of this change we won't know which PV code change did it - if any did.  
You don't give specfics but in my Jira 39 pods are failing (half of these are 
normal hierarchy failures until the ones actually busted get fixed)
https://jira.onap.org/browse/OOM-813

   Remember the job of both of our CD systems is specifically to catch these 
and eventually mark the commit causing it with ONAPCDBuilder -1 - so it is good 
we are catching them manually for now - as long as they are not config issues 
or red herrings - hence the need for more than one type of undercloud.


state
AWS, amsterdam, ubuntu user = ?
AWS, beijing, ubuntu user = OK (20180319)
AWS, beijing, root user = ?
Azure, amsterdam, ubuntu user = OK (20180319)  
http://jenkins.onap.cloud/job/oom_azure_deployment/13/console
Azure, beijing, ubuntu user = BUSTED (20180319)
Azure, beijing, root user = in progress now (ete 75 min) - but a previous 
instance before the 14th is ok

AWS is fine
http://jenkins.onap.info/job/oom-cd/2410/console
Azure has issues on master not amsterdam on the ubuntu user
http://jenkins.onap.cloud/job/oom-cd-master/13/console



When my next run comes up - I will get the error directly from the k8s console 
(these are deleted by now)

master

pending containers=39

onap  aaf-6c64db8fdd-fgwxb   0/1   Running  
 0  27m

onap  aai-data-router-6fbb8695d4-9s6w2   0/1   
CreateContainerConfigError0  27m

onap  aai-elasticsearch-7f66545fdf-q7gnh 0/1   
CreateContainerConfigError0  27m

onap  aai-model-loader-service-7768db4744-lj9bg  0/2   
CreateContainerConfigError0  27m

onap  aai-resources-9f95b9b6d-qrhs5  0/2   
CreateContainerConfigError0  27m

onap  aai-search-data-service-99dff479c-fr8bh0/2   
CreateContainerConfigError0  27m

onap  aai-service-5698ddc455-npsm6   0/1   Init:0/1 
 2  27m

onap  aai-sparky-be-57bd9944b5-cmqvc 0/2   
CreateContainerConfigError0  27m

onap  aai-traversal-df4b45c4-sjtlx   0/2   Init:0/1 
 0  27m

onap  appc-67c6b9d477-n64mk  0/2   
CreateContainerConfigError0  27m

onap  appc-dgbuilder-68c68ff84b-x6dst0/1   Init:0/1 
 0  27m

onap  clamp-6889598c4-76mww  0/1   Init:0/1 
 2  27m

onap  clamp-mariadb-78c46967b8-2w922 0/1   
CreateContainerConfigError0  27m

onap  log-elasticsearch-6ff5b5459d-2zq2b 0/1   
CreateContainerConfigError0  27m

onap  log-kibana-54c978c5fc-457gb0/1   Init:0/1 

Re: [onap-discuss] New OOM deployment issues

[Gary Wu]

so it is good 
we are catching them manually for now - as long as they are not config issues 
or red herrings - hence the need for more than one type of undercloud.


state
AWS, amsterdam, ubuntu user = ?
AWS, beijing, ubuntu user = OK (20180319)
AWS, beijing, root user = ?
Azure, amsterdam, ubuntu user = OK (20180319)  
http://jenkins.onap.cloud/job/oom_azure_deployment/13/console
Azure, beijing, ubuntu user = BUSTED (20180319)
Azure, beijing, root user = in progress now (ete 75 min) - but a previous 
instance before the 14th is ok

AWS is fine
http://jenkins.onap.info/job/oom-cd/2410/console
Azure has issues on master not amsterdam on the ubuntu user
http://jenkins.onap.cloud/job/oom-cd-master/13/console



When my next run comes up - I will get the error directly from the k8s console 
(these are deleted by now)

master

pending containers=39

onap  aaf-6c64db8fdd-fgwxb   0/1   Running  
 0  27m

onap  aai-data-router-6fbb8695d4-9s6w2   0/1   
CreateContainerConfigError0  27m

onap  aai-elasticsearch-7f66545fdf-q7gnh 0/1   
CreateContainerConfigError0  27m

onap  aai-model-loader-service-7768db4744-lj9bg  0/2   
CreateContainerConfigError0  27m

onap  aai-resources-9f95b9b6d-qrhs5  0/2   
CreateContainerConfigError0  27m

onap  aai-search-data-service-99dff479c-fr8bh0/2   
CreateContainerConfigError0  27m

onap  aai-service-5698ddc455-npsm6   0/1   Init:0/1 
 2  27m

onap  aai-sparky-be-57bd9944b5-cmqvc 0/2   
CreateContainerConfigError0  27m

onap  aai-traversal-df4b45c4-sjtlx   0/2   Init:0/1 
 0  27m

onap  appc-67c6b9d477-n64mk  0/2   
CreateContainerConfigError0  27m

onap  appc-dgbuilder-68c68ff84b-x6dst0/1   Init:0/1 
 0  27m

onap  clamp-6889598c4-76mww  0/1   Init:0/1 
 2  27m

onap  clamp-mariadb-78c46967b8-2w922 0/1   
CreateContainerConfigError0  27m

onap  log-elasticsearch-6ff5b5459d-2zq2b 0/1   
CreateContainerConfigError0  27m

onap  log-kibana-54c978c5fc-457gb0/1   Init:0/1 
 2  27m

onap  log-logstash-5f6fbc4dff-t2hh9  0/1   Init:0/1 
 2  27m

onap  mso-555464596b-t5fc2   0/2   Init:0/1 
 2  28m

onap  mso-mariadb-5448666ccc-kddh6   0/1   
CreateContainerConfigError0  28m

onap  multicloud-framework-57687dc8c-nf7pk   0/2   
CreateContainerConfigError0  27m

onap  multicloud-vio-5bfb9f68db-g6j7h0/2   
CreateContainerConfigError0  27m

onap  policy-brmsgw-5f445cfcfb-wzb88 0/1   Init:0/1 
 2  27m

onap  policy-drools-5b67c475d6-pv6kt 0/2   
CreateContainerConfigError0  27m

onap  policy-pap-79577c6947-fhfxb0/2   
Init:CrashLoopBackOff 8  27m

onap  policy-pdp-7d5c76bf8d-st7js0/2   Init:0/1 
 2  27m

onap  portal-apps-7ddfc4b6bd-g7nhk   0/2   
Init:CreateContainerConfigError   0  27m

onap  portal-vnc-7dcbf79f66-7c6p60/1   Init:0/4 
 2  27m

onap  portal-widgets-6979b47c48-5kr860/1   
CreateContainerConfigError0  27m

onap  robot-f6d55cc87-t2wgd  0/1   
CreateContainerConfigError0  27m

onap  sdc-fe-6d4b87c978-2v5x20/2   
CreateContainerConfigError0  27m

onap  sdnc-0 0/2   Init:0/1 
 2  28m

onap  sdnc-dbhost-0  0/2   Pending  
 0  28m

onap  sdnc-dgbuilder-794d686f78-296zf0/1   Init:0/1 
 2  28m

onap  sdnc-dmaap-listener-8595c8f6c-vgzxt0/1   Init:0/1 
 2  28m

onap  sdnc-portal-69b79b6646-p4x8k   0/1   Init:0/1 
 2 

Re: [onap-discuss] New OOM deployment issues

[Michael O'Brien]

Checking.
   There is documentation that the OOM and Integration team keeps up to date on 
this below
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes#ONAPonKubernetes-SoftwareRequirements
   You should be ok with Kubernetes 1.8.x in master - but we need to verify 
post 1.8.6
   Since Rancher 1.6.14 is still at 1.8.5 (it should not move) 1.8.6 is the 
closest.
   I am running 2.6.1 helm server/client and K8s 1.8.5 server, 1.8.6 client.
   Normally for the CD you should be on a locked down version of Kubernetes, 
Rancher, Helm and (not so much docker).
   My script has these hardcoded for each branch
https://gerrit.onap.org/r/#/c/32019/11/install/rancher/oom_rancher_setup.sh
https://jira.onap.org/browse/OOM-716

  if [ "$BRANCH" == "amsterdam" ]; then
RANCHER_VERSION=1.6.10
KUBECTL_VERSION=1.7.7
HELM_VERSION=2.3.0
DOCKER_VERSION=1.12
  else
RANCHER_VERSION=1.6.14
KUBECTL_VERSION=1.8.6
HELM_VERSION=2.6.1
DOCKER_VERSION=17.03
  fi

  These versions are what I run for everything AWS, Azure, Openstack, VMWare
  Unfortunately AWS had a resource issue on the 17th so all spot VMs were reset 
when the market rose to peak - I lost a week of runs and only have hourly 
master traffic from 17 Mar at 1400h.

When I get some time I will retest a couple more environments to narrow it 
down - as I also need to get master working in azure (currently only amsterdam 
deploys there).

  /michael




From: Gary Wu [mailto:gary.i...@huawei.com]
Sent: Monday, March 19, 2018 15:52
To: Michael O'Brien <frank.obr...@amdocs.com>; onap-discuss@lists.onap.org
Subject: RE: New OOM deployment issues

Hi Michael,

For reference, both of my environments (Wind River / TLAB) are running OOM as 
the root user, and they seem to be failing the same error as your 
Azure/master/ubuntu environment, so it may not be an issue with root user vs. 
ubuntu user.

The failures started on 3/16 between noon and 6 Pacific time.  The only thing 
new that happened in my environments during that time seems to be the docker 
image rancher/k8s:v1.8.9-rancher-1.2.  For comparison, another environment I 
deployed a week ago is on rancher/k8s:v1.8.5-rancher4 which was working fine.  
This is without me updating any rancher-specific configuration between the two, 
so maybe Rancher itself has changed?

Can you check your various OOM environments and see what versions of 
rancher/k8s they're on?

Thanks,
Gary


From: Michael O'Brien [mailto:frank.obr...@amdocs.com]
Sent: Monday, March 19, 2018 11:36 AM
To: Gary Wu <gary.i...@huawei.com<mailto:gary.i...@huawei.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: RE: New OOM deployment issues

Gary,
  Adding onap-discuss as we should always discuss ONAP health in public - as it 
may also catch the attention of anyone who did these changes.

  Yes when working on OOM-710 over the weekend noticed this issue specific to 
only my azure instances running in Ubuntu (I was working in master mainly so 
did not check amsterdam for a while - just checked and it is OK)  - Assumed it 
was my arm template as I am testing the entrypoint script in the script 
extension point.   I say this because I have always had this problem in Azure 
specific only to the Ubuntu user - since I started running as Ubuntu instead of 
just root (around Friday)

  Undercloud seems to be the issue here - mixed with some config in master 
(azure/openstack have issues, aws does not)
  Running the install in root did not have the issue on either AWS:EBS or Azure 
- before the 15th and only in azure/openstack:ubuntu:master after
  Running on AWS EBS also does not have the issue on Ubuntu or root

  So it looks like a permissions change on the config files sensitive to the 
file system.
  There were only 3 commits to master since the 15th so it does not look like 
any of those 3 would cause it
https://gerrit.onap.org/r/#/q/status:merged+oom

   Raised the following just for tracking - but until we go through the exact 
start of this change we won't know which PV code change did it - if any did.  
You don't give specfics but in my Jira 39 pods are failing (half of these are 
normal hierarchy failures until the ones actually busted get fixed)
https://jira.onap.org/browse/OOM-813

   Remember the job of both of our CD systems is specifically to catch these 
and eventually mark the commit causing it with ONAPCDBuilder -1 - so it is good 
we are catching them manually for now - as long as they are not config issues 
or red herrings - hence the need for more than one type of undercloud.


state
AWS, amsterdam, ubuntu user = ?
AWS, beijing, ubuntu user = OK (20180319)
AWS, beijing, root user = ?
Azure, amsterdam, ubuntu user = OK (20180319)  
http://jenkins.onap.cloud/job/oom_azure_deployment/13/console
Azure, beijing, ubuntu user = BUSTED (20180319)
Azure, beijing, root user = in progress now (ete 75 min) - but a previous 
instance before the 14th is ok

Re: [onap-discuss] New OOM deployment issues

[Gary Wu]

Hi Michael,

For reference, both of my environments (Wind River / TLAB) are running OOM as 
the root user, and they seem to be failing the same error as your 
Azure/master/ubuntu environment, so it may not be an issue with root user vs. 
ubuntu user.

The failures started on 3/16 between noon and 6 Pacific time.  The only thing 
new that happened in my environments during that time seems to be the docker 
image rancher/k8s:v1.8.9-rancher-1.2.  For comparison, another environment I 
deployed a week ago is on rancher/k8s:v1.8.5-rancher4 which was working fine.  
This is without me updating any rancher-specific configuration between the two, 
so maybe Rancher itself has changed?

Can you check your various OOM environments and see what versions of 
rancher/k8s they're on?

Thanks,
Gary


From: Michael O'Brien [mailto:frank.obr...@amdocs.com]
Sent: Monday, March 19, 2018 11:36 AM
To: Gary Wu <gary.i...@huawei.com>; onap-discuss@lists.onap.org
Subject: RE: New OOM deployment issues

Gary,
  Adding onap-discuss as we should always discuss ONAP health in public - as it 
may also catch the attention of anyone who did these changes.

  Yes when working on OOM-710 over the weekend noticed this issue specific to 
only my azure instances running in Ubuntu (I was working in master mainly so 
did not check amsterdam for a while - just checked and it is OK)  - Assumed it 
was my arm template as I am testing the entrypoint script in the script 
extension point.   I say this because I have always had this problem in Azure 
specific only to the Ubuntu user - since I started running as Ubuntu instead of 
just root (around Friday)

  Undercloud seems to be the issue here - mixed with some config in master 
(azure/openstack have issues, aws does not)
  Running the install in root did not have the issue on either AWS:EBS or Azure 
- before the 15th and only in azure/openstack:ubuntu:master after
  Running on AWS EBS also does not have the issue on Ubuntu or root

  So it looks like a permissions change on the config files sensitive to the 
file system.
  There were only 3 commits to master since the 15th so it does not look like 
any of those 3 would cause it
https://gerrit.onap.org/r/#/q/status:merged+oom

   Raised the following just for tracking - but until we go through the exact 
start of this change we won't know which PV code change did it - if any did.  
You don't give specfics but in my Jira 39 pods are failing (half of these are 
normal hierarchy failures until the ones actually busted get fixed)
https://jira.onap.org/browse/OOM-813

   Remember the job of both of our CD systems is specifically to catch these 
and eventually mark the commit causing it with ONAPCDBuilder -1 - so it is good 
we are catching them manually for now - as long as they are not config issues 
or red herrings - hence the need for more than one type of undercloud.


state
AWS, amsterdam, ubuntu user = ?
AWS, beijing, ubuntu user = OK (20180319)
AWS, beijing, root user = ?
Azure, amsterdam, ubuntu user = OK (20180319)  
http://jenkins.onap.cloud/job/oom_azure_deployment/13/console
Azure, beijing, ubuntu user = BUSTED (20180319)
Azure, beijing, root user = in progress now (ete 75 min) - but a previous 
instance before the 14th is ok

AWS is fine
http://jenkins.onap.info/job/oom-cd/2410/console
Azure has issues on master not amsterdam on the ubuntu user
http://jenkins.onap.cloud/job/oom-cd-master/13/console



When my next run comes up - I will get the error directly from the k8s console 
(these are deleted by now)

master

pending containers=39

onap  aaf-6c64db8fdd-fgwxb   0/1   Running  
 0  27m

onap  aai-data-router-6fbb8695d4-9s6w2   0/1   
CreateContainerConfigError0  27m

onap  aai-elasticsearch-7f66545fdf-q7gnh 0/1   
CreateContainerConfigError0  27m

onap  aai-model-loader-service-7768db4744-lj9bg  0/2   
CreateContainerConfigError0  27m

onap  aai-resources-9f95b9b6d-qrhs5  0/2   
CreateContainerConfigError0  27m

onap  aai-search-data-service-99dff479c-fr8bh0/2   
CreateContainerConfigError0  27m

onap  aai-service-5698ddc455-npsm6   0/1   Init:0/1 
 2  27m

onap  aai-sparky-be-57bd9944b5-cmqvc 0/2   
CreateContainerConfigError0  27m

onap  aai-traversal-df4b45c4-sjtlx   0/2   Init:0/1 
 0  27m

onap  appc-67c6b9d477-n64mk  0/2   
CreateContainerConfigError0  27m

onap  appc-dgbuilder-68c68ff84b-x6dst0/1   Init:0/1 
 0  27m

onap  clamp-6889598c4-76mww  0/1   In

Re: [onap-discuss] New OOM deployment issues

[Michael O'Brien]

Gary,
  Adding onap-discuss as we should always discuss ONAP health in public - as it 
may also catch the attention of anyone who did these changes.

  Yes when working on OOM-710 over the weekend noticed this issue specific to 
only my azure instances running in Ubuntu (I was working in master mainly so 
did not check amsterdam for a while - just checked and it is OK)  - Assumed it 
was my arm template as I am testing the entrypoint script in the script 
extension point.   I say this because I have always had this problem in Azure 
specific only to the Ubuntu user - since I started running as Ubuntu instead of 
just root (around Friday)

  Undercloud seems to be the issue here - mixed with some config in master 
(azure/openstack have issues, aws does not)
  Running the install in root did not have the issue on either AWS:EBS or Azure 
- before the 15th and only in azure/openstack:ubuntu:master after
  Running on AWS EBS also does not have the issue on Ubuntu or root

  So it looks like a permissions change on the config files sensitive to the 
file system.
  There were only 3 commits to master since the 15th so it does not look like 
any of those 3 would cause it
https://gerrit.onap.org/r/#/q/status:merged+oom

   Raised the following just for tracking - but until we go through the exact 
start of this change we won't know which PV code change did it - if any did.  
You don't give specfics but in my Jira 39 pods are failing (half of these are 
normal hierarchy failures until the ones actually busted get fixed)
https://jira.onap.org/browse/OOM-813

   Remember the job of both of our CD systems is specifically to catch these 
and eventually mark the commit causing it with ONAPCDBuilder -1 - so it is good 
we are catching them manually for now - as long as they are not config issues 
or red herrings - hence the need for more than one type of undercloud.


state
AWS, amsterdam, ubuntu user = ?
AWS, beijing, ubuntu user = OK (20180319)
AWS, beijing, root user = ?
Azure, amsterdam, ubuntu user = OK (20180319)  
http://jenkins.onap.cloud/job/oom_azure_deployment/13/console
Azure, beijing, ubuntu user = BUSTED (20180319)
Azure, beijing, root user = in progress now (ete 75 min) - but a previous 
instance before the 14th is ok

AWS is fine
http://jenkins.onap.info/job/oom-cd/2410/console
Azure has issues on master not amsterdam on the ubuntu user
http://jenkins.onap.cloud/job/oom-cd-master/13/console



When my next run comes up - I will get the error directly from the k8s console 
(these are deleted by now)

master

pending containers=39

onap  aaf-6c64db8fdd-fgwxb   0/1   Running  
 0  27m

onap  aai-data-router-6fbb8695d4-9s6w2   0/1   
CreateContainerConfigError0  27m

onap  aai-elasticsearch-7f66545fdf-q7gnh 0/1   
CreateContainerConfigError0  27m

onap  aai-model-loader-service-7768db4744-lj9bg  0/2   
CreateContainerConfigError0  27m

onap  aai-resources-9f95b9b6d-qrhs5  0/2   
CreateContainerConfigError0  27m

onap  aai-search-data-service-99dff479c-fr8bh0/2   
CreateContainerConfigError0  27m

onap  aai-service-5698ddc455-npsm6   0/1   Init:0/1 
 2  27m

onap  aai-sparky-be-57bd9944b5-cmqvc 0/2   
CreateContainerConfigError0  27m

onap  aai-traversal-df4b45c4-sjtlx   0/2   Init:0/1 
 0  27m

onap  appc-67c6b9d477-n64mk  0/2   
CreateContainerConfigError0  27m

onap  appc-dgbuilder-68c68ff84b-x6dst0/1   Init:0/1 
 0  27m

onap  clamp-6889598c4-76mww  0/1   Init:0/1 
 2  27m

onap  clamp-mariadb-78c46967b8-2w922 0/1   
CreateContainerConfigError0  27m

onap  log-elasticsearch-6ff5b5459d-2zq2b 0/1   
CreateContainerConfigError0  27m

onap  log-kibana-54c978c5fc-457gb0/1   Init:0/1 
 2  27m

onap  log-logstash-5f6fbc4dff-t2hh9  0/1   Init:0/1 
 2  27m

onap  mso-555464596b-t5fc2   0/2   Init:0/1 
 2  28m

onap  mso-mariadb-5448666ccc-kddh6   0/1   
CreateContainerConfigError0  28m

onap  multicloud-framework-57687dc8c-nf7pk   0/2   
CreateContainerConfigError0  27m

onap  multicloud-vio-5bfb9f68db-g6j7h0/2   
CreateContainerConfigError

[onap-discuss] Invitation: [multicloud] weekly (updated Mar. 19, 2018) @ Mon Mar 19, 2018 5pm - 6pm (PDT) (onap-discuss@lists.onap.org)

[kpaul]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180320T00Z
DTEND:20180320T01Z
DTSTAMP:20180319T162547Z
ORGANIZER;CN=ONAP Meetings and Events:mailto:linuxfoundation.org_1rmtb5tpr3
 uc8f76fmflplo...@group.calendar.google.com
UID:7ol6e6u03um114on1553vta...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=lxin...@vmware.com;X-NUM-GUESTS=0:mailto:lxin...@vmware.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=onap-discuss@lists.onap.org;X-NUM-GUESTS=0:mailto:onap-discuss@list
 s.onap.org
CREATED:20180319T162546Z
DESCRIPTION:From PC\, Mac\, Linux\, iOS or Android: https://zoom.us/j/90570
 41886\n\niPhone one-tap (US Toll): +16465588656\,\,9057041886# or +14086380
 968\,\,9057041886#\n\nTelephone:\nDial: +1 646 558 8656 (US Toll) or +1 408
  638 0968 (US Toll)\n+1 855 880 1246 (US Toll Free)\n+1 877 369 0926 (US To
 ll Free)\nMeeting ID: 905 704 1886\n\nhttps://wiki.onap.org/pages/viewpage.
 action?pageId=6591499\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of t
 he description.\n\nView your event at https://www.google.com/calendar/event
 ?action=VIEW=N29sNmU2dTAzdW0xMTRvbjE1NTN2dGFjMnAgb25hcC1kaXNjdXNzQGxpc3
 RzLm9uYXAub3Jn=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1m
 bHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tYmEzYTdkOThmNGM3MzMzNzQwNDEyNGM
 0YmJhZTE2MTljMjMzZTRiYQ=America%2FLos_Angeles=en=1.\n-::~:~::~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180319T162547Z
LOCATION: https://zoom.us/j/9057041886
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[multicloud]  weekly (updated Mar. 19\, 2018)
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Canceled event: [multicloud] Team Meeting (updated Feb. 2, 2018) @ Weekly from 2pm to 3pm on Monday (PST) (onap-discuss@lists.onap.org)

[kpaul]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20180212T14
DTEND;TZID=America/Los_Angeles:20180212T15
RRULE:FREQ=WEEKLY;BYDAY=MO
DTSTAMP:20180319T162109Z
ORGANIZER;CN=ONAP Meetings and Events:mailto:linuxfoundation.org_1rmtb5tpr3
 uc8f76fmflplo...@group.calendar.google.com
UID:6e0ae6shqe3iac0tiq0ufkq...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gi
 l.hellm...@windriver.com;X-NUM-GUESTS=0:mailto:gil.hellm...@windriver.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=on
 ap-disc...@lists.onap.org;X-NUM-GUESTS=0:mailto:onap-discuss@lists.onap.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=lx
 in...@vmware.com;X-NUM-GUESTS=0:mailto:lxin...@vmware.com
CREATED:20180202T223006Z
DESCRIPTION:From PC\, Mac\, Linux\, iOS or Android:\;https://zoom.us/j/9057041886;>https
 ://zoom.us/j/9057041886iPhone one-tap (US Toll): +
 16465588656\,\,9057041886# or +14086380968\,\,9057041886#Telephone:Dial: +1 646 558 8656 (US Toll) or +1 408 638
  0968 (US Toll)+1 855 880 1246 (US Toll Free)+1 877 369 0926 (US Toll Free)Meeting ID: 905 704 1886
 https://wiki.onap.org/pages/v
 iewpage.action?pageId=6591499">https://wiki.onap.org/pages/viewpage.action?
 pageId=6591499
LAST-MODIFIED:20180319T162109Z
LOCATION:https://zoom.us/j/9057041886
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:[multicloud] Team Meeting (updated Feb. 2\, 2018)
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] ONAP issues

[Asha Rawat]

Hi Team,

I am trying to get some information regarding ONAP which i am unable to
find in google .

could anyone please help on this?

Regards,
Asha Rawat
8588896641
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [Onap-arc] Update on "Consistent Representation and Identification of a cloud region in ONAP"

[Yang, Bin]

Hi Chris,

   This is the update on the following action and progress on this 
"Representation and Identification of a cloud region in ONAP" issue.

I had reached out to PTL of VID/SO/SDNC/Integration team and join weekly 
meetings of each project. I briefed this issue again on those meetings and 
brought attentions of each project team.
VID team agreed that it is doable to fix this issue but need to evaluate the 
effort.
SDNC team promised to evaluate the impact and effort to fix this issue.
Integration team acknowledged this issue and Helen preferred the long term 
solution.
SO team preferred long term solutions as well, and Seshu suggest we fix this 
issue by some use case in future releases.

Since we have passed the M3 API freezing milestone, I think this is not likely 
to get this issue resolved in Beijing release.

So I would like to have your suggestion on how to proceed : should we propose 
some use case, or make sure some use case in Casablanca Release could cover the 
feature to resolve this issue?

Thanks.


Best Regards,
Bin Yang,Solution Readiness Team,Wind River
Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
Skype: yangbincs993

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yang, Bin
Sent: Monday, March 05, 2018 10:12 AM
To: seshu.kuma...@huawei.com; Sonsino, Ofir; TIMONEY, DAN; Yunxia Chen 
 (helen.c...@huawei.com); PUTHENPURA, SARAT (SARAT)
Cc: Christopher Donley (Chris) (christopher.don...@huawei.com); Hellmann, Gil; 
onap-discuss@lists.onap.org
Subject: [onap-discuss] Issue to be resolved: Consistent Representation and 
Identification of a cloud region in ONAP

Hello Seshu, Dan, Helen, Sarat,
and those are concerned on Representation and Identification of a cloud region 
in ONAP,

   The expanding to multiple clouds is a key metric for success of 
ONAP, and you might already be aware the fact that: With ONAP Amsterdam 
release, it is kind of tricky and error prone to onboard a new cloud region 
into ONAP for the end-to-end test cases.
I had learned that fact and got plenty help from this community during setting 
up a demo of using ONAP to orchestrate the Clearwater vIMS across 2 cloud 
regions. So I posted the workarounds on wiki: 
https://wiki.onap.org/pages/viewpage.action?pageId=25431491
   At the same time, I had presented this issue and the short term 
workaround and long term solution to ONAP community during both VF2F meeting 
and ONAP Arch meeting.  I got suggestion from Chris Donley and Stephen that we 
need figure out if it is possible to fix that in Beijing release. So that is 
why I come to you and wondering if I can get your kindly support. The summary 
of issue and the solutions can be found at wiki: 
https://wiki.onap.org/download/attachments/25429038/HowToAddNewCloudRegionAndThoughts.pdf?version=2=1520214136460=v2

To highlight what the issue is and what the help is expected from your teams:
   1, There are multiple places to represent a single cloud region 
and inconsistent identification of a cloud region makes it is hard to onboard a 
new cloud region
   2, The short term workaround places another constraint on the 
"cloud-owner", while the long term solution impose the API changes between 
VID/SO/SDNC, and perhaps OOF as well.

Please let me know if you can add this as an agenda to your weekly meeting this 
week so that I can explain more the details and estimate the possibility to fix 
that in Beijing release.

Thanks.

Best Regards,
Bin Yang,Solution Readiness Team,Wind River
Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
Skype: yangbincs993

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

[onap-discuss] [ONAP Helpdesk #53786] [linuxfoundation.org #53786] RE: onap wiki 502 this morning

[Michael O'Brien via RT]

We are good now

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Michael O'Brien
Sent: Monday, March 19, 2018 08:55
To: onap-discuss@lists.onap.org
Cc: helpd...@onap.org
Subject: [onap-discuss] onap wiki 502 this morning

Hi, getting a bad gateway specific only to the wiki as of 0850 EDT GMT-5

https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure

Wiki is more than just reference - we also use it for live demo's and recording 
ongoing work
/michael

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 


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

Re: [onap-discuss] onap wiki 502 this morning

[Michael O'Brien]

We are good now

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Michael O'Brien
Sent: Monday, March 19, 2018 08:55
To: onap-discuss@lists.onap.org
Cc: helpd...@onap.org
Subject: [onap-discuss] onap wiki 502 this morning

Hi, getting a bad gateway specific only to the wiki as of 0850 EDT GMT-5

https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure

Wiki is more than just reference - we also use it for live demo's and recording 
ongoing work
/michael

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

[onap-discuss] Schedule for ONS

[Kenny Paul]

The Program Committee has finished with scheduling and the agenda for the ONAP 
breakout sessions at ONS have been set.
https://wiki.lfnetworking.org/display/LN/ONAP+Project+Specific+Breakouts 


I do not have any info on remote attendance at this time, but it our intent to 
have that available. I will inform everyone once I have that.

Presenters can upload your presentation materials as appropriate. PLEASE 
remember to upload PDFs!!!


Best Regards, 
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone

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

[onap-discuss] onap wiki 502 this morning

[Michael O'Brien]

Hi, getting a bad gateway specific only to the wiki as of 0850 EDT GMT-5

https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Microsoft+Azure

Wiki is more than just reference - we also use it for live demo's and recording 
ongoing work
/michael

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB cluster is not available"

[Alexis de Talhouët]

Reason why it’s using the external IP is so DCAE can communicate with DMaaP. As 
DCAE query SDC to get the UEB IPs (DMaaP), if those IPs are internal to K8S, 
DCAE VMs won’t be able to communicate with DMaaP, hence close-loop won’t work.

Alexis

> On Mar 18, 2018, at 4:55 PM, abdelmuhaimen.sea...@orange.com wrote:
> 
> Here's the output showing now DE is UP after correcting IP Address.
> 
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc/v1/distributionUebCluster 
>    -H 'Accept: 
> application/json'   -H 'Content-Type: application/json'   -H 
> 'X-ECOMP-InstanceID: mso'   -H 'authorization: Basic 
> dmlkOktwOGJKNFNYc3pNMFdYbGhhazNlSGxjc2UyZ0F3ODR2YW9HR21KdlV5MlU='
> {"uebServerList":["10.43.205.37","10.43.205.37"]}
> 
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc2/rest/healthCheck 
> 
> > ^C
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc2/rest/healthCheck 
> 
> {
>   "sdcVersion": "1.1.0",
>   "siteMode": "unknown",
>   "componentsInfo": [
> {
>   "healthCheckComponent": "BE",
>   "healthCheckStatus": "UP",
>   "version": "1.1.0",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "TITAN",
>   "healthCheckStatus": "UP",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "DE",
>   "healthCheckStatus": "UP",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "CASSANDRA",
>   "healthCheckStatus": "UP",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "ON_BOARDING",
>   "healthCheckStatus": "UP",
>   "version": "1.1.0",
>   "description": "OK",
>   "componentsInfo": [
> {
>   "healthCheckComponent": "ZU",
>   "healthCheckStatus": "UP",
>   "version": "0.2.0",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "BE",
>   "healthCheckStatus": "UP",
>   "version": "1.1.0",
>   "description": "OK"
> },
> {
>   "healthCheckComponent": "CAS",
>   "healthCheckStatus": "UP",
>   "version": "2.1.17",
>   "description": "OK"
> }
>   ]
> }
>   ]
> }
> From: SEAUDI Abdelmuhaimen OBS/CSO
> Sent: Sunday, March 18, 2018 10:34 PM
> To: Ahmad, Munir; onap-discuss@lists.onap.org 
> 
> Subject: RE: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB 
> cluster is not available"
> 
> Hi Munir,
> 
> Thanks for your reply.
> 
> I found out that the reason SDC is using the external IP of DMAAP, instead of 
> the internal IP, is the configuration file 
> /dockerdata-nfs/onap/sdc/environments/AUTO.json, which mentions :
> "ueb_url_list": "84.39.48.90,84.39.48.90"
> 
> Shouldn't SDC be configured with the K8S internal IP address of the DMAAP, 
> for example in my case it should be the IP Address 10.43.205.37 as per the 
> output from kubectl get services below ?
> 
> How can this be corrected ?
> 
> kubectl get services --all-namespaces
> NAMESPACE NAME   CLUSTER-IP  EXTERNAL-IP   
> PORT(S)  
> AGE
> onap-message-router   dmaap  10.43.205.37   
> 3904:30227/TCP,3905:30226/TCP
> 24m
> root@olc-k8s:~# 
> From: Ahmad, Munir [munir.ah...@bell.ca ]
> Sent: Sunday, March 18, 2018 4:21 AM
> To: SEAUDI Abdelmuhaimen OBS/CSO; onap-discuss@lists.onap.org 
> 
> Subject: Re: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB 
> cluster is not available"
> 
> Hi,
>  
> It may have to do with the order your sdc containers started. Try deleting 
> your pods in the following order
>  
> sdc-es
> sdc-cs
> sdc-kb
> sdc-be
> sdc-fe
>  
>  
> Thanks
> Munir
> From:  > on behalf of 
> "abdelmuhaimen.sea...@orange.com " 
> >
> Date: Saturday, March 17, 2018 at 5:31 AM
> To: "onap-discuss@lists.onap.org " 
> >
> Subject: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB cluster 
> is not available"
>  
> Hi,
>  
> I have a minimal ONAP Depoloyment on K8S running.
>  
> If I try to distribute a new service in SDC, I get Error code POL5000, status 
> code: 500, Internal Server Error. Please try again later.
>  
> Regarding the output below, what does UEB Cluster not 

[onap-discuss] [model][vCPE] Things missing in Onap Tosca DM?

[Lu, Lianhao]

Hi Guys,

I'm now looking at the vCPE usecase 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246168#UseCase:ResidentialBroadbandvCPE(Approved)-Description),
 and try to convert its heat template(https://git.onap.org/demo/tree/heat/vCPE) 
into latest onap Tosca  DM 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile ). I 
found the following things in heat and can NOT find the corresponding mapping 
in the Tosca DM.

1. SSH key pairs for VM
Heat supports creating ssh keypair for VM to enable login with ssh 
public/private keys. However I could not find corresponding in latest onap 
tosca DM. Should we support this in tosca DM?

2. cloudinit user scripts
In heat, vCPE uses cloudinit user script to executed within the VM after VM has 
been launched to configure the VNF softwares within the VM. However, in tosca 
DM, there is no direct mapping to such things in VDU. Should I use 
tosca.interfaces.node.lifecycle.Standard interface instead or should we add new 
properties in VDU (see openstack tacker's VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L239
 )? The new userdata should also support inputs like 
tosca.interfaces.node.lifecycle.Standard interface.

3. pre-created networks:
vCPE will use 2 pre-created networks which are created when ONAP itself is 
being deployed: onap_public_net is used to make VM be able to connect to 
internet, onap_private_net is the oam network which is used to make some of the 
vCPE vnf talk to some onap component(e.g. dcae_collector). So this requires the 
VNF VM to be connected to a pre-created network. However in tosca DM, it seems 
that there is no way to specify a VDU created by tosca DM connecting to a 
pre-created network which is already created during ONAP deployment using heat. 
 Should we add an property in tosca.nodes.nfv.VnfVirtualLink to indicate 
whether the network is pre-created or not?

4. VM metadata
vCPE also uses VM metadata which is missing in Tosca DM's VDU. Should we add 
this?( see openstack tacker's VDU as an example 
https://github.com/openstack/tacker/blob/master/tacker/tosca/lib/tacker_nfv_defs.yaml#L198
 )?

Best Regards,
-Lianhao
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

[Parviz Yegani]

Hi Huabing,

Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target architecture (R3+)!

I added the following item to the agenda for today’s tiger team call:

-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.
Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com



From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani ; Christopher Donley (Chris) 

Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards


Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond



1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as

· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)

· allowing free choice of development tech stack

· flexible route rules to enable traffic steering and canary release

· monitoring and tracing visibility

· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating the possibility of integration of Istio and ONAP right now.



2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.



3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

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