Re: [onap-discuss] VNF configuration via VFC

[Singh Kalra, Mandeep]

Hi,

  Thanks a lot Srini and Haibin.

  vCPE use case which is TOSCA format create VNF via G-VNFM. We are 
debugging it.
  >> Is the vCPE TOSCA part of Bejing release, the tosca equivalent 
of vCPE uses VFC or ARIA ?

  And also for the VNF configuration as Srini mentioned EMS will be 
used for VNF configuration but below statement is part of the approved volte 
use case ::
As a stretch goal in VOLTE use case was the VNF configuration using ansible
>> What will be the approach here via VFC ?



Regards
Mandeep

From: Huang, Haibin [mailto:haibin.hu...@intel.com]
Sent: Thursday, June 14, 2018 6:22 AM
To: Addepalli, Srinivasa R ; Singh Kalra, 
Mandeep ; onap-discuss@lists.onap.org
Subject: [External] RE: VNF configuration via VFC

Hi Mandeep Sirinivasa,

vCPE use case which is TOSCA format create VNF via G-VNFM. We are debugging it.

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Addepalli, Srinivasa R
Sent: Thursday, June 14, 2018 6:18 AM
To: Singh Kalra, Mandeep 
mailto:mandeep.singh.ka...@accenture.com>>; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

Hi Mandeep,

We had same question a while ago when we are trying to figure out the changes 
required in VF-C project to leverage HPA.

VOLTE team, please correct if this understanding is not right:

  *   It appears that G-VNFM is not being leveraged to bring up VNFs.
  *   Every VNF has its own sVNFM from the VNF vendor.

Due to this,  HPA team is felt that they should modify NSLCM (upper level Micro 
Service that talks to G-VNFM or one of sVNFMs for a given VNF) to integrate 
with OOF to get the best site and compute flavors.

Also, I think there is a need to create VNF (may be using vFW) via G-VNFM for 
testing any OOF features/policies.

On VNF configuration : As I understand, vendors are providing their own EMS in 
addition to sVNFM for configuring the VNF applications.  I don't think APP-C is 
used to configure VOLTE VNFs. I may be wrong here. Please correct.

Thanks
Srini


From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Singh Kalra, Mandeep
Sent: Wednesday, June 13, 2018 11:36 AM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

Hi,

  Will appreciate some inputs on the below queries.
  And also if GVNFM is used in any of the use cases ?


Regards
Mandeep
From: Singh Kalra, Mandeep
Sent: Tuesday, June 12, 2018 5:37 PM
To: onap-discuss@lists.onap.org
Subject: VNF configuration via VFC

Hi,


 I have a doubt about the VNF configuration through VFC. 
After the VNFs are instantiated is there any interface/APIs using which the 
VNFs can be configured ?
As a stretch goal in VOLTE use case was the VNF 
configuration using ansible.
  Can you please share your views on this ?

  Also, is the gvnfm used in any use case in R2 ?

Regards
Mandeep




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy. Your privacy is important to us. Accenture uses your personal data only 
in compliance with data protection laws. For further information on how 
Accenture processes your personal data, please see our privacy statement at 
https://www.accenture.com/us-en/privacy-policy.
__

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

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Yang, Bin]

Hi Arash,

   Your assumption is correct, multicloud plugins have the choice 
to use Go or any other language since they are located in separate repo and 
delivered as separate micro-services.

   Given the facts that k8s plugin is a brand new multicloud 
component and the MultiCloud’s committers/contributors are more 
involved/concerned on the collaboration/contribution here, this discussion 
thread is to brainstorm on the opinions with regarding to pros/cons of each 
choice.

Ideally we can achieve consensus after fully discussion/debating. But if not, I 
expect there is some guideline/approach to settle down the disruption so that 
everyone could follow.

Thanks.

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

From: Arash Hekmat [mailto:arash.hek...@amdocs.com]
Sent: Wednesday, June 13, 2018 10:04 PM
To: HU, BIN; Yang, Bin; ADDEPALLI, SRINIVASA; MORALES RUVALCABA, VICTOR; 
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua; Huang, Yun
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Hi MultiCloud Team,

My 2 cents here.

I believe if below conditions are true, the K8S plugin can be implemented in Go 
or any other language. But if they are not true, it should probably match 
MultiCould’s core and use Python, for all the maintainability and integration 
concerns already raised.

The K8S plugin can use Go or any other language if:


  1.  It has its own separate git repo
  2.  It runs in its own separate docker container
  3.  It does not directly call or share MultiCould’s Python framework

Arash

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Wednesday, June 13, 2018 2:02 AM
To: Yang, Bin ; ADDEPALLI, SRINIVASA 
; MORALES RUVALCABA, VICTOR 
; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua ; Huang, Yun 

Subject: Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

If I understand correctly, there are 2 types of concerns regarding Go language 
(v.s. Python) here:

  *   Implementation, integration and testing: e.g. CI/CD integration, reuse of 
shared services etc.
  *   Long-term community support with the appropriate expertise in Go language.

The 2nd one, i.e long-term community support is actually the biggest concern. 
For example, after K8S plugin is developed with Go language, but the original 
Go developer no longer works in ONAP, do we have a pool of Go developers in 
ONAP community that can comfortably take over the work of maintenance and 
further evolving K8S Plugin? Or will then-current developers have to re-develop 
K8S Plugin with Python or Java because most of ONAP developers are Python or 
Java developers?

If there are very few Go developers in ONAP community, using Go language 
certainly brings huge risk of continuous support, maintenance and evolution in 
the future.

My 2 cents
Thanks
Bin

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: ADDEPALLI, SRINIVASA 
mailto:srinivasa.r.addepa...@intel.com>>; 
MORALES RUVALCABA, VICTOR 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org; HU, BIN 
mailto:bh5...@att.com>>
Cc: Huang, Yun mailto:yun.hu...@windriver.com>>; 
HUANG, HAIBIN mailto:haibin.hu...@intel.com>>; Zhang, 
Xiaohua mailto:xiaohua.zh...@windriver.com>>
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the architecture perspective it is irrelevant w.r.t. 
how to implement the plugin service, hence up to developers/contributors’ 
choice. However, it is worth to think again for following reasons:

1, Leverage and Scale
   Aligning to existing practice of multicloud plugin 
implementation enables developers focus on the core value of the plugin, e.g. 
mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As 
part of ONAP projects it is required that the multicloud k8s plugin be 
integrated with CI/CD process and other shared services (e.g. AAF, centralized 
logging, etc.)  Right now CI/CD support projects with python binding very well, 
and the logging AOP facility for Python is well supported, I don’t know if 
there is off-the-shelf utility for golang available yet. If multicloud k8s 
plugin align to the existing practice of openstack plugin and vio plugin, then 
you don’t have to invest further time/cost on those effort.


2, Facilitate more participation from current multicloud committers/contributors
   multicloud committers/contributors has been working on python 
already for a long 

Re: [onap-discuss] VNF configuration via VFC

[Huang, Haibin]

Hi Mandeep Sirinivasa,

vCPE use case which is TOSCA format create VNF via G-VNFM. We are debugging it.

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Addepalli, Srinivasa R
Sent: Thursday, June 14, 2018 6:18 AM
To: Singh Kalra, Mandeep ; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

Hi Mandeep,

We had same question a while ago when we are trying to figure out the changes 
required in VF-C project to leverage HPA.

VOLTE team, please correct if this understanding is not right:

-  It appears that G-VNFM is not being leveraged to bring up VNFs.

-  Every VNF has its own sVNFM from the VNF vendor.

Due to this,  HPA team is felt that they should modify NSLCM (upper level Micro 
Service that talks to G-VNFM or one of sVNFMs for a given VNF) to integrate 
with OOF to get the best site and compute flavors.

Also, I think there is a need to create VNF (may be using vFW) via G-VNFM for 
testing any OOF features/policies.

On VNF configuration : As I understand, vendors are providing their own EMS in 
addition to sVNFM for configuring the VNF applications.  I don't think APP-C is 
used to configure VOLTE VNFs. I may be wrong here. Please correct.

Thanks
Srini


From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Singh Kalra, Mandeep
Sent: Wednesday, June 13, 2018 11:36 AM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

Hi,

  Will appreciate some inputs on the below queries.
  And also if GVNFM is used in any of the use cases ?


Regards
Mandeep
From: Singh Kalra, Mandeep
Sent: Tuesday, June 12, 2018 5:37 PM
To: onap-discuss@lists.onap.org
Subject: VNF configuration via VFC

Hi,


 I have a doubt about the VNF configuration through VFC. 
After the VNFs are instantiated is there any interface/APIs using which the 
VNFs can be configured ?
As a stretch goal in VOLTE use case was the VNF 
configuration using ansible.
  Can you please share your views on this ?

  Also, is the gvnfm used in any use case in R2 ?

Regards
Mandeep




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy. Your privacy is important to us. Accenture uses your personal data only 
in compliance with data protection laws. For further information on how 
Accenture processes your personal data, please see our privacy statement at 
https://www.accenture.com/us-en/privacy-policy.
__

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

Re: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

[VENKATESH KUMAR, VIJAY]

Suraj,
I don’t believe Amsterdam SDC support component model generation. It may be 
available in Beijing; will have to defer to SDC team to explain the setup 
though. Michael/Igor – Can you help?

Thanks,
-Vijay

From: Bisht, Suraj (Nokia - US/Irving) 
Sent: Wednesday, June 13, 2018 10:42 AM
To: VENKATESH KUMAR, VIJAY ; HWANG, MICHAEL 
; fu.guangr...@zte.com.cn; JI, LUSHENG 
; LANDO, MICHAEL 
Cc: peng.congc...@zte.com.cn; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

Hi Vijay, Mike,

We have created data-format.json and component.json for our application but I 
am still not clear what should in csar package to design an DCAE component in 
SDC , kindly share details or any link explaining entire process in Amsterdam 
release.

Thanks,
Suraj

From: VENKATESH KUMAR, VIJAY [mailto:vv7...@att.com]
Sent: Tuesday, June 12, 2018 5:25 PM
To: Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>; HWANG, MICHAEL 
mailto:mhw...@research.att.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>; LANDO, MICHAEL 
mailto:ml6...@intl.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

HI Suraj, It was not part of Amsterdam, DCAE-DS was included in Beijing 
release. I’ve copied Michael from SDC team who can give more info.

However DCAE-DS was not used for model/blueprint generation in R2 (component 
blueprints were created manually). For R3, current plans are to onboard the 
DCAE MS through SDC/DS.

Thanks,
Vijay

From: Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>
Sent: Tuesday, June 12, 2018 12:42 PM
To: VENKATESH KUMAR, VIJAY mailto:vv7...@att.com>>; HWANG, 
MICHAEL mailto:mhw...@research.att.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

Hi Vijay, Mike

Is DCAE-DS tool available in Amsterdam release? I can’t find any link in SDC 
GUI to access DCAE-DS tool kindly clarify how to access DCAE-DS, is there any 
specific ONAP component IP/link need to be used?
Some background for our use case
We are trying to create a micro service/application in DCAE to 
Publish/Subscribe particular events through new application.

Thanks,
Suraj

From: VENKATESH KUMAR, VIJAY [mailto:vv7...@att.com]
Sent: Friday, June 08, 2018 1:34 PM
To: HWANG, MICHAEL mailto:mhw...@research.att.com>>; 
Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

The component spec example of VES collector is available on the same 
wiki

The ToscaLab tool used for model generations are supported by DCAE-DS under SDC 
project (updated the onboarding sequence flow which had an older version).

Thanks,
Vijay

From: HWANG, MICHAEL
Sent: Friday, June 08, 2018 10:05 AM
To: Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org; VENKATESH 
KUMAR, VIJAY mailto:vv7...@att.com>>
Subject: Re: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

+Vijay

The dcae_cli tool does not generate csar packages.  It is intended that the 
dcae_cli tool should generate tosca models which are to be used by the dcae 
design studio which is in sdc.  Currently this tosca model generation is a 
separate step.

Regarding self service of tosca model generation, @Lusheng who can help him 
with the tooling?

Regarding samples, one of the features of the dcae onboarding experience is to 
provide a shared catalog of components so that developers can share and browse. 
 However, this sort of environment is not being hosted right now.  @Vijay could 
you provide the ves's component spec as a sample?
On 06/04/2018 05:36 PM, Bisht, Suraj (Nokia - US/Irving) wrote:
Hi Mike,

Thanks for your response,
I was going through following link

Re: [onap-discuss] VNF configuration via VFC

[Addepalli, Srinivasa R]

Hi Mandeep,

We had same question a while ago when we are trying to figure out the changes 
required in VF-C project to leverage HPA.

VOLTE team, please correct if this understanding is not right:

-It appears that G-VNFM is not being leveraged to bring up VNFs.

-Every VNF has its own sVNFM from the VNF vendor.

Due to this,  HPA team is felt that they should modify NSLCM (upper level Micro 
Service that talks to G-VNFM or one of sVNFMs for a given VNF) to integrate 
with OOF to get the best site and compute flavors.

Also, I think there is a need to create VNF (may be using vFW) via G-VNFM for 
testing any OOF features/policies.

On VNF configuration : As I understand, vendors are providing their own EMS in 
addition to sVNFM for configuring the VNF applications.  I don't think APP-C is 
used to configure VOLTE VNFs. I may be wrong here. Please correct.

Thanks
Srini


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Singh Kalra, Mandeep
Sent: Wednesday, June 13, 2018 11:36 AM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

Hi,

  Will appreciate some inputs on the below queries.
  And also if GVNFM is used in any of the use cases ?


Regards
Mandeep
From: Singh Kalra, Mandeep
Sent: Tuesday, June 12, 2018 5:37 PM
To: onap-discuss@lists.onap.org
Subject: VNF configuration via VFC

Hi,


 I have a doubt about the VNF configuration through VFC. 
After the VNFs are instantiated is there any interface/APIs using which the 
VNFs can be configured ?
As a stretch goal in VOLTE use case was the VNF 
configuration using ansible.
  Can you please share your views on this ?

  Also, is the gvnfm used in any use case in R2 ?

Regards
Mandeep




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy. Your privacy is important to us. Accenture uses your personal data only 
in compliance with data protection laws. For further information on how 
Accenture processes your personal data, please see our privacy statement at 
https://www.accenture.com/us-en/privacy-policy.
__

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

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Addepalli, Srinivasa R]

Hi Bin,

I think you answered questions  yourself ☺. It is easy to learn, secure 
language, performant and many are eager to learn.  There are some good number 
of people with Golang experience (thanks to some of the work that was done in 
Beijing) already in ONAP community.  Also,


-we see the need for using Prometheus (or similar) for event/statistics 
aggregation micro service to satisfy the MVP of Edge-automation use case. Since 
Prometheus is developed in golang, any ancillary packages/glues are also 
expected to be developed in golang.

-ISTIO service mesh technology is being seriously looked at to replace 
existing MSB and simplify security.  If this is adopted, any enhancements 
related to service mesh would normally happen in golang as ISTIO is developed 
in golang.

With above two, I have a confidence that we will have more developers in golang.

Thanks
Srini


From: HU, BIN [mailto:bh5...@att.com]
Sent: Wednesday, June 13, 2018 12:26 PM
To: Addepalli, Srinivasa R ; HEKMAT, ARASH 
; Yang, Bin (Wind River) ; 
Morales, Victor ; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua (Wind River) ; Huang, Yun (Wind 
River) 
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Hi Srini and Arash,

Thank you for the great information. I am truly with you, and there is no doubt 
that K8S can be implemented with Go language, and I do see the merit of Go 
language that will provide great value in implementation.

The concern here is not related to technology of Go language, as I mentioned 
earlier. Please understand that I do believe that Go language is easy to learn, 
and savvy developers all eager to learn new technologies. GoLang client is also 
well maintained by Kubernetes community as Victor mentioned in a different 
email.

The situation is that K8S Plugin will be implemented and maintained in ONAP 
community. So for the long-term sustainability, a reasonable size of developer 
pool in ONAP community is needed to continuously maintain our own K8S Plugin 
code base in ONAP.

I just want to know: do you have a plan to grow a reasonable size of developer 
pool in ONAP community so that K8S Plugin implementation with Go can be 
continuously maintained and evolved in ONAP?

Thanks
Bin

From: Addepalli, Srinivasa R [mailto:srinivasa.r.addepa...@intel.com]
Sent: Wednesday, June 13, 2018 7:36 AM
To: HEKMAT, ARASH mailto:arash.hek...@amdocs.com>>; 
HU, BIN mailto:bh5...@att.com>>; Yang, Bin (Wind River) 
mailto:bin.y...@windriver.com>>; Morales, Victor 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua (Wind River) 
mailto:xiaohua.zh...@windriver.com>>; Huang, Yun 
(Wind River) mailto:yun.hu...@windriver.com>>
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Yes Arash.  K8S plugin has its own repo and will be set (currently one) micro 
service run as container.  We don’t intend to call Python calls from Go 
programs.  So, answer is Yes for all three points you have mentioned in your 
email.

Hi Bin,

I don’t mean to be pedantic here.  Sorry if it appears so.


1.  (Can be argumentative and may become philosophical discussion)It is 
very easy to learn go-lang.  I don’t see it as big issue either maintaining it 
or even developing.  Engineers who contributed to SMS, Distributed KV Store 
(done as part of R2) were new to go and could learn in matter of days/weeks.

2.  Code size is very small – Hence easy to adopt in Edge locations (if 
there is a need in future).

3.  Static type checking – Less error prone.

4.  Performance of golang based system is higher. (Bring up is very fast 
and it is just 10-20% lower performance than C/C++)

5.  K8S Client in go-lang always little bit ahead of other language 
bindings.  Go-client is maintained as part of Kubernetes project.

6.  GoCrypto has a way to talk to HSMs. If there is a need to secure keys, 
password, secrets,  then the support is already available. Java Crypto has 
similar support, but python does not have it (yet).

7.  Many micro service projects are developed in golang. It is quite 
mature. Many CNCF projects are developed in golang.

https://hackernoon.com/5-reasons-why-we-switched-from-python-to-go-4414d5f42690

Since ONAP is micro-service based, language choice for a given micro-service 
should not matter.  And you will find more and more Engineers with go skillset 
with increasing popularity Kubernetes and micro-service architecture

Thanks
Srini


From: Arash Hekmat [mailto:arash.hek...@amdocs.com]
Sent: Wednesday, June 13, 2018 7:04 AM
To: HU, BIN 

[onap-discuss] [it-infrastructure-alerts] JIRA security maintainance. Saturday June 16 at 8am Pacific (3pm UTC)

[Jessica Wagantall]

What: The Linux Foundation will be performing a JIRA security upgrade

When: Saturday June 16 at 8am Pacific (3pm UTC)

Why:The bundled Atlassian OAuth plugin allows arbitrary HTTP requests to be
proxied
CVE-2017-9506 (https://jira.atlassian.com/browse/JRASERVER-65862)

Impact: Jira will be unavailable for 1 hour

Notices will be posted to the mailing lists at the start and end of the
maintenance.
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] How to clear ONAP OOM POD logs

[abdelmuhaimen.seaudi]

Hi,

I found a couple of ways to empty out an existing large file, using Output 
redirection " > filename " or "truncate -s 0 filename ".

I checked after emptying the file and I see the logs continue normally.

This way, I don't need to delete the pod or kill a process.

root@olc-bjng-3:/var/lib/docker/containers# du -h -d 1 | sort -r -h | head
49G .
35G ./b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410
14G ./ad21fbc6614f291c50838e860587f568f45eea1956408f1ec078bb08fcfd5879
root@olc-bjng-3:/var/lib/docker/containers# > 
./b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410/b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410-json.log
root@olc-bjng-3:/var/lib/docker/containers/b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410#
 ls -l
total 60
-rw-r- 1 root root   193 Jun 13 
20:52b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410-json.log
drwx-- 2 root root  4096 Jun 11 15:41checkpoints
-rw-r--r-- 1 root root 48062 Jun 11 15:41config.v2.json
-rw-r--r-- 1 root root  1696 Jun 11 15:41hostconfig.json
root@olc-bjng-3:/var/lib/docker/containers/b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410#
 cat b9df9b8587860364bc4267889f81712544e5aa6ce3e5ab33c8c3842fd014c410-json.log
{"log":"2018-06-13 20:52:12.925  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:52:12.932234368Z"}
{"log":"2018-06-13 20:52:23.078  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:52:23.084544646Z"}
{"log":"2018-06-13 20:52:33.217  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:52:33.218096153Z"}
{"log":"2018-06-13 20:52:43.401  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:52:43.402126811Z"}
{"log":"2018-06-13 20:52:53.549  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:52:53.549390405Z"}
{"log":"2018-06-13 20:53:03.715  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:53:03.715633889Z"}
{"log":"2018-06-13 20:53:13.866  INFO 451 --- [   main] 
o.o.u.server.util.DmaapSubscriber: response content is 
:[]\n","stream":"stdout","time":"2018-06-13T20:53:13.867127823Z"}



Sent from Samsung Mobile.


 Original message 
From: Mandeep Khinda
Date:13/06/2018 3:54 PM (GMT+02:00)
To: SEAUDI Abdelmuhaimen OBS/CSO , onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] How to clear logs

Hi,
It is a good question as I have had my disk filled before too.

I have removed the massive .json log file from /var/lib/docker/containers/*/* 
in the past after stopping the container and docker daemon but I would not 
suggest unless you were okay with having to re-deploy the pod as I have had 
mixed success.

I think we need to add some documentation to the K8s cluster build requirements 
to enable some sort of log rotation for the docker containers.
I found this:
https://kubernetes.io/docs/concepts/cluster-administration/logging/

Kubernetes currently is not responsible for rotating logs, but rather a 
deployment tool should set up a solution to address that. For example, in 
Kubernetes clusters, deployed by the kube-up.sh script, there is a 
logrotate tool configured to run each 
hour

By default, the docker daemon uses json-file as its logging driver and this 
thing comes out of the box with an unlimited size.

https://docs.docker.com/config/containers/logging/json-file/#usage

Try setting “--log-opt max-size=[SIZE]m” in your k8s nodes where docker is 
running to prevent this from happening again.

Thanks,
Mandeep

From:  on behalf of 
"abdelmuhaimen.sea...@orange.com" 
Date: Wednesday, June 13, 2018 at 2:09 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] How to clear logs

Hi,

I was able to resolve an issue with an ONAP OOM Pod that resulted in a log file 
filling up 95% of the disk space.

Now, what if I need to clear the logs of an ONAP OOM pod ? What is the correct 
process ?

Thanks.

Abdelmuhaimen Seaudi
Orange Labs Egypt
Email: abdelmuhaimen.sea...@orange.com
Mobile: +2012 84644 733


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le 

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[HU, BIN]

Hi Srini and Arash,

Thank you for the great information. I am truly with you, and there is no doubt 
that K8S can be implemented with Go language, and I do see the merit of Go 
language that will provide great value in implementation.

The concern here is not related to technology of Go language, as I mentioned 
earlier. Please understand that I do believe that Go language is easy to learn, 
and savvy developers all eager to learn new technologies. GoLang client is also 
well maintained by Kubernetes community as Victor mentioned in a different 
email.

The situation is that K8S Plugin will be implemented and maintained in ONAP 
community. So for the long-term sustainability, a reasonable size of developer 
pool in ONAP community is needed to continuously maintain our own K8S Plugin 
code base in ONAP.

I just want to know: do you have a plan to grow a reasonable size of developer 
pool in ONAP community so that K8S Plugin implementation with Go can be 
continuously maintained and evolved in ONAP?

Thanks
Bin

From: Addepalli, Srinivasa R [mailto:srinivasa.r.addepa...@intel.com]
Sent: Wednesday, June 13, 2018 7:36 AM
To: HEKMAT, ARASH ; HU, BIN ; Yang, 
Bin (Wind River) ; Morales, Victor 
; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua (Wind River) ; Huang, Yun (Wind 
River) 
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Yes Arash.  K8S plugin has its own repo and will be set (currently one) micro 
service run as container.  We don’t intend to call Python calls from Go 
programs.  So, answer is Yes for all three points you have mentioned in your 
email.

Hi Bin,

I don’t mean to be pedantic here.  Sorry if it appears so.


1.   (Can be argumentative and may become philosophical discussion)It is 
very easy to learn go-lang.  I don’t see it as big issue either maintaining it 
or even developing.  Engineers who contributed to SMS, Distributed KV Store 
(done as part of R2) were new to go and could learn in matter of days/weeks.

2.   Code size is very small – Hence easy to adopt in Edge locations (if 
there is a need in future).

3.   Static type checking – Less error prone.

4.   Performance of golang based system is higher. (Bring up is very fast 
and it is just 10-20% lower performance than C/C++)

5.   K8S Client in go-lang always little bit ahead of other language 
bindings.  Go-client is maintained as part of Kubernetes project.

6.   GoCrypto has a way to talk to HSMs. If there is a need to secure keys, 
password, secrets,  then the support is already available. Java Crypto has 
similar support, but python does not have it (yet).

7.   Many micro service projects are developed in golang. It is quite 
mature. Many CNCF projects are developed in golang.

https://hackernoon.com/5-reasons-why-we-switched-from-python-to-go-4414d5f42690

Since ONAP is micro-service based, language choice for a given micro-service 
should not matter.  And you will find more and more Engineers with go skillset 
with increasing popularity Kubernetes and micro-service architecture

Thanks
Srini


From: Arash Hekmat [mailto:arash.hek...@amdocs.com]
Sent: Wednesday, June 13, 2018 7:04 AM
To: HU, BIN mailto:bh5...@att.com>>; Yang, Bin (Wind River) 
mailto:bin.y...@windriver.com>>; Addepalli, Srinivasa R 
mailto:srinivasa.r.addepa...@intel.com>>; 
Morales, Victor mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua (Wind River) 
mailto:xiaohua.zh...@windriver.com>>; Huang, Yun 
(Wind River) mailto:yun.hu...@windriver.com>>
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Hi MultiCloud Team,

My 2 cents here.

I believe if below conditions are true, the K8S plugin can be implemented in Go 
or any other language. But if they are not true, it should probably match 
MultiCould’s core and use Python, for all the maintainability and integration 
concerns already raised.

The K8S plugin can use Go or any other language if:

(1)   It has its own separate git repo
(2)   It runs in its own separate docker container
(3)   It does not directly call or share MultiCould’s Python framework

Arash

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Wednesday, June 13, 2018 2:02 AM
To: Yang, Bin mailto:bin.y...@windriver.com>>; 
ADDEPALLI, SRINIVASA 
mailto:srinivasa.r.addepa...@intel.com>>; 
MORALES RUVALCABA, VICTOR 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua 

Re: [onap-discuss] VNF configuration via VFC

[Singh Kalra, Mandeep]

Hi,

  Will appreciate some inputs on the below queries.
  And also if GVNFM is used in any of the use cases ?


Regards
Mandeep
From: Singh Kalra, Mandeep
Sent: Tuesday, June 12, 2018 5:37 PM
To: onap-discuss@lists.onap.org
Subject: VNF configuration via VFC

Hi,


 I have a doubt about the VNF configuration through VFC. 
After the VNFs are instantiated is there any interface/APIs using which the 
VNFs can be configured ?
As a stretch goal in VOLTE use case was the VNF 
configuration using ansible.
  Can you please share your views on this ?

  Also, is the gvnfm used in any use case in R2 ?

Regards
Mandeep




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy. Your privacy is important to us. Accenture uses your personal data only 
in compliance with data protection laws. For further information on how 
Accenture processes your personal data, please see our privacy statement at 
https://www.accenture.com/us-en/privacy-policy.
__

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

[onap-discuss] [LOG] Logging scope change for POMBA TSC vote (post orchestration model based audit)

[Michael O'Brien]

Team,
   Heads up for the next TSC meeting - I added an item for a vote on expanding 
the scope of the logging-analytics project for POMBA (post orchestration model 
based audit)
   Jon Fannar Karlsson Taylor and Sharon Chisholm have hosted two 1 hour 
meetings over the last 3 weeks with the Architecture Subcommittee on Tuesdays.
   There are notes from both meetings and a faq below for your reference.


The POMBA (post orchestration model based audit) has had 2 meetings with the 
Architecture subcommittee detailed on

Logging Scope Change for POMBA seed 
code

Frequently Asked 
Questions

The last meeting gave the OK to start working in the logging-analytics repo 
from the arch and security principals.
https://wiki.onap.org/display/DW/TSC+2018-06-14+Meeting+Agenda


thank you
/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

[onap-discuss] Canceled event: [multicloud] Weekly Meeting (Updated April 23, 2018) @ Mon Jun 18, 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: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:20180618T17
DTEND;TZID=America/Los_Angeles:20180618T18
DTSTAMP:20180613T163838Z
ORGANIZER;CN=ONAP Meetings and Events:mailto:linuxfoundation.org_1rmtb5tpr3
 uc8f76fmflplo...@group.calendar.google.com
UID:6ohoh3cu87m7q7dof9u9hlm...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=lx
 in...@vmware.com;X-NUM-GUESTS=0:mailto:lxin...@vmware.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
RECURRENCE-ID;TZID=America/Los_Angeles:20180618T17
CREATED:20180423T125457Z
DESCRIPTION:IFro
 m PC\, Mac\, Linux\, iOS or Android: https://zoom.us/j/
 9057041886" rel="nofollow" style="color: rgb(53\, 114\, 176)\; text-decorat
 ion: none\;">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
LAST-MODIFIED:20180613T163838Z
LOCATION:https://zoom.us/j/9057041886
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:[multicloud] Weekly Meeting (Updated April 23\, 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

Re: [onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[jessie jewitt]

Hello Deng Hui-
 Could you please clarify something for me. The ETSI "applied
stereotype", on which this column in the wiki table is based, has
"obsolete" as an artifact lifecycle option, with its definition supplied in
the IISOMI Modeling Guidelines. This is the definition of "obsolete" in
those guidelines. Is this what we should interpret this to mean? Will the
entity be kept in the model for at least one further release?
Thanks for your guidance,
Jessie

   -
*Obsolete *This stereotype indicates that the entity should not be used in
   new implementation and that attempts should be made to remove it from
   existing implementation. The entity should be kept in the model for at
   least one further release. The team has to decide on a case by case basis
   when to remove it from the model.



On Wed, Jun 13, 2018 at 8:23 AM, denghui (L)  wrote:

> Hello all,
>
>
>
> This is 1 week’s call for approval on the “obsolete legacy
> attributes/datatypes” proposal for the resource IM.
>
> The intention is to mark several attributes/datatypes of the current model
> as “obsoleted” as their functionalities are covered by some other
> attributes.
>
> Detailed information of the proposal can be found at:
> https://wiki.onap.org/display/DW/Obsolete+Legacy+Attributes , the
> proposed changes are marked in red.
>
>
>
> Thanks a lot for your review
>
> Best regards,
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [vnfrqts] M1 Project Plan draft available

[WRIGHT, STEVEN A]

I've pulled together a first draft for the project plan and M1 checklist for 
VNFRQTS. These are 
available
 on the project wiki.  I'd like to solicit comments before the Casablanca 
developer event. Please either email the list or myself (or both).
We reviewed the EPICs on the last project team call, but I'd like to have the 
Stories updated and aligned with the EPICs before the developer event next 
week. I will take a stab at this, but would certainly welcome comments/ 
feedback.
best regards
Steven Wright, MBA, PhD, JD.
[Tech Integration]
AT Services Inc.
1057 Lenox Park Blvd NE, STE 4D28
Atlanta, GA 30319

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

[onap-discuss] DMaaP Recommended protocols

[ARUL NAMBI]

Hi,

The security team is working on a page(
https://wiki.onap.org/display/DW/Recommended+Protocols) that gives an
outline of what protocols to use and what to avoid. Currently, we have
entries for Rest based clients and adding a section for SSH.

We wanted to add a section for DMaaP(Kafka) as well since it will be used
by multiple services. In my research for DMaaP, I see that there are 2 ways
you can use DMaap

   1. Using the REST-based API client
   2. Through the UI(DMD)

I want to confirm if there is any other way to communicate with DMaaP other
than the REST-based client or the UI. If there are other ways through with
the services interact with DMaaP then we need to add that to the
recommendation list as well.

So anyone from DMaaP team can confirm this that will be great.

Also if anyone else can think of any other protocols that is being used in
ONAP please let us know so that we can update the page.

Thanks

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

[onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[denghui (L)]

Hello all,

This is 1 week’s call for approval on the “obsolete legacy 
attributes/datatypes” proposal for the resource IM.
The intention is to mark several attributes/datatypes of the current model as 
“obsoleted” as their functionalities are covered by some other attributes.
Detailed information of the proposal can be found at: 
https://wiki.onap.org/display/DW/Obsolete+Legacy+Attributes , the proposed 
changes are marked in red.

Thanks a lot for your review
Best regards,

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

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Morales, Victor]

Hey there,

First of all, every of these points are valid but also they have different 
perspectives. From our technical perspective as Srini mentioned during the 
MultiCloud meeting, we decided to choose Go as a programing language because 
it’s GoLang client is well-maintained by the Kubernetes community compared with 
others (something similar happens for the python client in OpenStack). I want 
to add that its go routines paradigm makes developers life easier to build 
multi-thread applications and its tools ecosystem is mature enough.

Regarding the points that you mention:


· Implementation, integration and testing. There are other projects 
written in Go which have been integrated in ONAP. So, the effort to test them 
has been already done. Implement new mechanisms for the integration to other 
shared services is not a big deal given that all of them are offering a RESTful 
API which can be consumed by any language.

· Collaboration and support. I want to mention that this is an open 
source project which means that its code is accessible to anyone. At same time, 
there is no guarantee that any contributor can be assigned indefinitely to this 
and/or any project but IMHO, the way to mitigate this is being open in sense of 
sharing code, documentation and processes and building a community. Lastly Go 
has been grown [1] in terms of adoption and popularity and its simplicity makes 
an easy learning curve.

Regards,
Victor Morales

[1] https://www.tiobe.com/tiobe-index/go/


From: "HU, BIN" 
Date: Tuesday, June 12, 2018 at 11:02 PM
To: "Yang, Bin (Wind River)" , "Addepalli, Srinivasa R" 
, Victor Morales , 
"onap-discuss@lists.onap.org" 
Cc: "Huang, Yun (Wind River)" , "Huang, Haibin" 
, "Zhang, Xiaohua (Wind River)" 

Subject: RE: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

If I understand correctly, there are 2 types of concerns regarding Go language 
(v.s. Python) here:

-  Implementation, integration and testing: e.g. CI/CD integration, 
reuse of shared services etc.

-  Long-term community support with the appropriate expertise in Go 
language.

The 2nd one, i.e long-term community support is actually the biggest concern. 
For example, after K8S plugin is developed with Go language, but the original 
Go developer no longer works in ONAP, do we have a pool of Go developers in 
ONAP community that can comfortably take over the work of maintenance and 
further evolving K8S Plugin? Or will then-current developers have to re-develop 
K8S Plugin with Python or Java because most of ONAP developers are Python or 
Java developers?

If there are very few Go developers in ONAP community, using Go language 
certainly brings huge risk of continuous support, maintenance and evolution in 
the future.

My 2 cents
Thanks
Bin

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: ADDEPALLI, SRINIVASA ; MORALES RUVALCABA, 
VICTOR ; onap-discuss@lists.onap.org; HU, BIN 

Cc: Huang, Yun ; HUANG, HAIBIN 
; Zhang, Xiaohua 
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the architecture perspective it is irrelevant w.r.t. 
how to implement the plugin service, hence up to developers/contributors’ 
choice. However, it is worth to think again for following reasons:

1, Leverage and Scale
   Aligning to existing practice of multicloud plugin 
implementation enables developers focus on the core value of the plugin, e.g. 
mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As 
part of ONAP projects it is required that the multicloud k8s plugin be 
integrated with CI/CD process and other shared services (e.g. AAF, centralized 
logging, etc.)  Right now CI/CD support projects with python binding very well, 
and the logging AOP facility for Python is well supported, I don’t know if 
there is off-the-shelf utility for golang available yet. If multicloud k8s 
plugin align to the existing practice of openstack plugin and vio plugin, then 
you don’t have to invest further time/cost on those effort.


2, Facilitate more participation from current multicloud committers/contributors
   multicloud committers/contributors has been working on python 
already for a long time , and it is not surprising that many of them are 
willing to participate/contribute to this multicloud k8s plugin development. 
Assuming that Golang is not as widely adopted as Python so most of them is not 
that familiar with Golang compared to Python, it would lower the barrier for 
them to contribute if multicloud k8s plugin could adopt the same language and 
framework.

3, Decrease the maintenance cost from either community and the Service 

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Addepalli, Srinivasa R]

Hi Bin,

We will leverage the work done by SMS to talk to AAF/ISTIO, logging etc…
CI/CD process was already proven by other projects such as SMS & Distributed KV 
Store and same process can be leveraged.
In regards to skillset & maturity of go-lang & Python vs go : Let us not 
discuss (if you don’t mind)  as this can become a big rathole ☺.

Thanks
Srini


From: bin.y...@windriver.com [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: Addepalli, Srinivasa R ; Morales, Victor 
; onap-discuss@lists.onap.org; HU, BIN 
(bh5...@att.com) 
Cc: Huang, Yun (Wind River) ; Huang, Haibin 
; Zhang, Xiaohua (Wind River) 

Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the architecture perspective it is irrelevant w.r.t. 
how to implement the plugin service, hence up to developers/contributors’ 
choice. However, it is worth to think again for following reasons:

1, Leverage and Scale
   Aligning to existing practice of multicloud plugin 
implementation enables developers focus on the core value of the plugin, e.g. 
mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As 
part of ONAP projects it is required that the multicloud k8s plugin be 
integrated with CI/CD process and other shared services (e.g. AAF, centralized 
logging, etc.)  Right now CI/CD support projects with python binding very well, 
and the logging AOP facility for Python is well supported, I don’t know if 
there is off-the-shelf utility for golang available yet. If multicloud k8s 
plugin align to the existing practice of openstack plugin and vio plugin, then 
you don’t have to invest further time/cost on those effort.


2, Facilitate more participation from current multicloud committers/contributors
   multicloud committers/contributors has been working on python 
already for a long time , and it is not surprising that many of them are 
willing to participate/contribute to this multicloud k8s plugin development. 
Assuming that Golang is not as widely adopted as Python so most of them is not 
that familiar with Golang compared to Python, it would lower the barrier for 
them to contribute if multicloud k8s plugin could adopt the same language and 
framework.

3, Decrease the maintenance cost from either community and the Service 
Providers who will productize ONAP
   By align to the same practice and share the same building blocks 
across multicloud plugins, one committer/contributor support/maintain one 
plugin could also be possible to support another one with low cost to 
learn/understand it. This will decrease the TCO which is always a pain of open 
source product compared to those commercialized close source product.

4, facilitate pairwise/integration testing for fast release cadence
   It might not concern those architect, but it is really a pain 
for developers who support the pairwise/integration testing. Fortunately, 
python make our life better since it is possible to fix the bug on runtime and 
test it immediately, which reduce the cycle of debugging. I can share you some 
feedback from several PTLs whom I had supported during Pairwise/integration 
test if you are interested to know.

So it is my 2 cents, please let me know if you have other concerns/opinions and 
I am willing to learn them, 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: Wednesday, June 13, 2018 9:21 AM
To: ADDEPALLI, SRINIVASA; MORALES RUVALCABA, VICTOR; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [coe] Team meeting Agenda

Hi Srini, and all,

   With regarding to the “each deployment instance needs to be 
uniquely identified”,  what is the intention for this “uniquely identified”? I 
mean, who will care about/consume this unique ID?

IMHO, from multicloud NBI consumers’ perspective, I don’t get the point to 
identify uniquely each deployment instance of multicloud plugin for following 
reasons:
1, every multicloud plugin could be deployed as a cluster/replicated set of 
“deployment instances” within a single ONAP instance, but they all should 
expose the NBI via the same endpoint. I assume every multicloud plugin are 
stateless service so that the consumer’s requests can be distributed via MSB or 
some other load balance mechanism . In that case multicloud consumers are not 
aware the “multiple deployment instances” of any multicloud plugin.

2, every multicloud plugin 

Re: [onap-discuss] MSB - DCAE/VESCollector

[William Kurkian]

Thanks, that worked fone.

William

On Tue, Jun 12, 2018 at 5:40 PM, VENKATESH KUMAR, VIJAY 
wrote:

> Hi William,  The VEScollector is also exposed via Nodeport (30235 by
> default). You can configure the PNF to send events into   address>:30235/eventListener/v5.
>
>
>
> Regards,
>
> Vijay
>
> *From:* onap-discuss-boun...@lists.onap.org <
> onap-discuss-boun...@lists.onap.org> *On Behalf Of *William Kurkian
> *Sent:* Tuesday, June 12, 2018 2:51 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] MSB - DCAE/VESCollector
>
>
>
> Hello,
>
>
>
> Does anyone know how devices external to ONAP, such as a PNF, should
> access the VES Collector in a Kubernetes installation?
>
>
>
> One thing I looked at was querying the MSB, but it did not have the VES
> collector listed, at least in my current installation. I am a few weeks
> behind, so I don't know if it has been added since.
>
>
>
> Thanks,
>
> William Kurkian
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

[Bisht, Suraj (Nokia - US/Irving)]

Hi Vijay, Mike,

We have created data-format.json and component.json for our application but I 
am still not clear what should in csar package to design an DCAE component in 
SDC , kindly share details or any link explaining entire process in Amsterdam 
release.

Thanks,
Suraj

From: VENKATESH KUMAR, VIJAY [mailto:vv7...@att.com]
Sent: Tuesday, June 12, 2018 5:25 PM
To: Bisht, Suraj (Nokia - US/Irving) ; HWANG, MICHAEL 
; fu.guangr...@zte.com.cn; JI, LUSHENG 
; LANDO, MICHAEL 
Cc: peng.congc...@zte.com.cn; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

HI Suraj, It was not part of Amsterdam, DCAE-DS was included in Beijing 
release. I’ve copied Michael from SDC team who can give more info.

However DCAE-DS was not used for model/blueprint generation in R2 (component 
blueprints were created manually). For R3, current plans are to onboard the 
DCAE MS through SDC/DS.

Thanks,
Vijay

From: Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>
Sent: Tuesday, June 12, 2018 12:42 PM
To: VENKATESH KUMAR, VIJAY mailto:vv7...@att.com>>; HWANG, 
MICHAEL mailto:mhw...@research.att.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

Hi Vijay, Mike

Is DCAE-DS tool available in Amsterdam release? I can’t find any link in SDC 
GUI to access DCAE-DS tool kindly clarify how to access DCAE-DS, is there any 
specific ONAP component IP/link need to be used?
Some background for our use case
We are trying to create a micro service/application in DCAE to 
Publish/Subscribe particular events through new application.

Thanks,
Suraj

From: VENKATESH KUMAR, VIJAY [mailto:vv7...@att.com]
Sent: Friday, June 08, 2018 1:34 PM
To: HWANG, MICHAEL mailto:mhw...@research.att.com>>; 
Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

The component spec example of VES collector is available on the same 
wiki

The ToscaLab tool used for model generations are supported by DCAE-DS under SDC 
project (updated the onboarding sequence flow which had an older version).

Thanks,
Vijay

From: HWANG, MICHAEL
Sent: Friday, June 08, 2018 10:05 AM
To: Bisht, Suraj (Nokia - US/Irving) 
mailto:suraj.bi...@nokia.com>>; 
fu.guangr...@zte.com.cn; JI, LUSHENG 
mailto:l...@research.att.com>>
Cc: peng.congc...@zte.com.cn; 
onap-discuss@lists.onap.org; VENKATESH 
KUMAR, VIJAY mailto:vv7...@att.com>>
Subject: Re: [onap-discuss] 答复：Re: 答复：[dcae] dcae-cli Installation Failure

+Vijay

The dcae_cli tool does not generate csar packages.  It is intended that the 
dcae_cli tool should generate tosca models which are to be used by the dcae 
design studio which is in sdc.  Currently this tosca model generation is a 
separate step.

Regarding self service of tosca model generation, @Lusheng who can help him 
with the tooling?

Regarding samples, one of the features of the dcae onboarding experience is to 
provide a shared catalog of components so that developers can share and browse. 
 However, this sort of environment is not being hosted right now.  @Vijay could 
you provide the ves's component spec as a sample?
On 06/04/2018 05:36 PM, Bisht, Suraj (Nokia - US/Irving) wrote:
Hi Mike,

Thanks for your response,
I was going through following link
https://wiki.onap.org/display/DW/MicroServices+Onboarding

and I got impression that dcae_cli tool will be used to generate csar package 
which can be used in SDC during DCAE component design, is this not the case?

Can you guide me how to create SDC compliant template to create DCAE component 
if I have data-formats and component-spec json files?
If possible kindly share one sample to verify DCAE micro service component 
deployment.

Thanks,
Suraj

From: Michael Hwang [mailto:mhw...@research.att.com]

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Addepalli, Srinivasa R]

Yes Arash.  K8S plugin has its own repo and will be set (currently one) micro 
service run as container.  We don’t intend to call Python calls from Go 
programs.  So, answer is Yes for all three points you have mentioned in your 
email.

Hi Bin,

I don’t mean to be pedantic here.  Sorry if it appears so.


1.  (Can be argumentative and may become philosophical discussion)It is 
very easy to learn go-lang.  I don’t see it as big issue either maintaining it 
or even developing.  Engineers who contributed to SMS, Distributed KV Store 
(done as part of R2) were new to go and could learn in matter of days/weeks.

2.  Code size is very small – Hence easy to adopt in Edge locations (if 
there is a need in future).

3.  Static type checking – Less error prone.

4.  Performance of golang based system is higher. (Bring up is very fast 
and it is just 10-20% lower performance than C/C++)

5.  K8S Client in go-lang always little bit ahead of other language 
bindings.  Go-client is maintained as part of Kubernetes project.

6.  GoCrypto has a way to talk to HSMs. If there is a need to secure keys, 
password, secrets,  then the support is already available. Java Crypto has 
similar support, but python does not have it (yet).

7.  Many micro service projects are developed in golang. It is quite 
mature. Many CNCF projects are developed in golang.

https://hackernoon.com/5-reasons-why-we-switched-from-python-to-go-4414d5f42690

Since ONAP is micro-service based, language choice for a given micro-service 
should not matter.  And you will find more and more Engineers with go skillset 
with increasing popularity Kubernetes and micro-service architecture

Thanks
Srini


From: Arash Hekmat [mailto:arash.hek...@amdocs.com]
Sent: Wednesday, June 13, 2018 7:04 AM
To: HU, BIN ; Yang, Bin (Wind River) ; 
Addepalli, Srinivasa R ; Morales, Victor 
; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua (Wind River) ; Huang, Yun (Wind 
River) 
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

Hi MultiCloud Team,

My 2 cents here.

I believe if below conditions are true, the K8S plugin can be implemented in Go 
or any other language. But if they are not true, it should probably match 
MultiCould’s core and use Python, for all the maintainability and integration 
concerns already raised.

The K8S plugin can use Go or any other language if:

(1)   It has its own separate git repo
(2)   It runs in its own separate docker container
(3)   It does not directly call or share MultiCould’s Python framework

Arash

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Wednesday, June 13, 2018 2:02 AM
To: Yang, Bin mailto:bin.y...@windriver.com>>; 
ADDEPALLI, SRINIVASA 
mailto:srinivasa.r.addepa...@intel.com>>; 
MORALES RUVALCABA, VICTOR 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua 
mailto:xiaohua.zh...@windriver.com>>; Huang, Yun 
mailto:yun.hu...@windriver.com>>
Subject: Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

If I understand correctly, there are 2 types of concerns regarding Go language 
(v.s. Python) here:
-Implementation, integration and testing: e.g. CI/CD integration, reuse 
of shared services etc.
-Long-term community support with the appropriate expertise in Go 
language.

The 2nd one, i.e long-term community support is actually the biggest concern. 
For example, after K8S plugin is developed with Go language, but the original 
Go developer no longer works in ONAP, do we have a pool of Go developers in 
ONAP community that can comfortably take over the work of maintenance and 
further evolving K8S Plugin? Or will then-current developers have to re-develop 
K8S Plugin with Python or Java because most of ONAP developers are Python or 
Java developers?

If there are very few Go developers in ONAP community, using Go language 
certainly brings huge risk of continuous support, maintenance and evolution in 
the future.

My 2 cents
Thanks
Bin

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: ADDEPALLI, SRINIVASA 
mailto:srinivasa.r.addepa...@intel.com>>; 
MORALES RUVALCABA, VICTOR 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org; HU, BIN 
mailto:bh5...@att.com>>
Cc: Huang, Yun mailto:yun.hu...@windriver.com>>; 
HUANG, HAIBIN mailto:haibin.hu...@intel.com>>; Zhang, 
Xiaohua mailto:xiaohua.zh...@windriver.com>>
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the 

Re: [onap-discuss] DMaaP recommended Protocols

[Addepalli, Srinivasa R]

Sunil from DMAPP team gave a presentation on DMAPP in Edge-automation use case 
group.  You are right that as in R2,  DMAPP hides kafka under RESTful API, but 
It appears that DMAPP will expose Kafka to outside entities to communicate 
using Kafka APIs in Casablanca.

Thanks
Srini


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Arul Nambi
Sent: Wednesday, June 13, 2018 7:07 AM
To: onap-discuss@lists.onap.org; onap-sec...@lists.onap.org
Subject: [onap-discuss] DMaaP recommended Protocols

Hi,
The security team is working on a 
page(https://wiki.onap.org/display/DW/Recommended+Protocols) that gives an 
outline of what protocols to use and what to avoid. Currently, we have entries 
for Rest based clients and adding a section for SSH.
We wanted to add a section for DMaaP(Kafka) as well since it will be used by 
multiple services. In my research for DMaaP, I see that there are 2 ways you 
can use DMaap

  1.  Using the REST-based API client
  2.  Through the UI(DMD)
I want to confirm if there is any other way to communicate with DMaaP other 
than the REST-based client or the UI. If there are other ways through with the 
services interact with DMaaP then we need to add that to the recommendation 
list as well.
So anyone from DMaaP team can confirm this that will be great.
Also if anyone else can think of any other protocols that is being used in ONAP 
please let us know so that we can update the page.
Thanks
Arul

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] DMaaP recommended Protocols

[Arul Nambi]

Hi,
The security team is working on a 
page(https://wiki.onap.org/display/DW/Recommended+Protocols) that gives an 
outline of what protocols to use and what to avoid. Currently, we have entries 
for Rest based clients and adding a section for SSH.
We wanted to add a section for DMaaP(Kafka) as well since it will be used by 
multiple services. In my research for DMaaP, I see that there are 2 ways you 
can use DMaap

  1.  Using the REST-based API client
  2.  Through the UI(DMD)
I want to confirm if there is any other way to communicate with DMaaP other 
than the REST-based client or the UI. If there are other ways through with the 
services interact with DMaaP then we need to add that to the recommendation 
list as well.
So anyone from DMaaP team can confirm this that will be great.
Also if anyone else can think of any other protocols that is being used in ONAP 
please let us know so that we can update the page.
Thanks
Arul

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] [coe] Meeting's survey

[Morales, Victor]

Hi Bin,

Sadly, the survey was closed last week given as results that time. From my 
side, I’m going to do my best to collect and publish the minutes. We can make 
another survey later but for now I’d prefer to use this new time.

Regards,
Victor Morales

From: "bin.y...@windriver.com" 
Date: Tuesday, June 12, 2018 at 6:34 PM
To: Victor Morales , "HU, BIN" , 
"Addepalli, Srinivasa R" , Munish Agarwal 
, "onap-discuss@lists.onap.org" 
, "Shankar, Shashank Kumar" 
, "Yeleswarapu, Ramamani" 

Subject: RE: [coe] Meeting's survey

Hi Victor,

   Is this survey closed?  The current schedule is not friendly for 
developers in China, could you help re-open the survey so that we can find out 
the time slot accommodating everyone participant?

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 Morales, Victor
Sent: Friday, May 25, 2018 5:55 AM
To: HU, BIN; ADDEPALLI, SRINIVASA; Munish Agarwal; onap-discuss@lists.onap.org; 
SHANKAR, SHASHANK KUMAR; YELESWARAPU, RAMAMANI
Subject: [onap-discuss] [coe] Meeting's survey

Hey there,

Maybe I was the only confused about the time for this meeting but it could be a 
good time to propose a different time. So please vote for the best time that 
works for you.

https://www.surveymonkey.com/r/FRSKR85

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

Re: [onap-discuss] ONAP Portal access from outside

[Arul Nambi]

Hi Pavithra,
Did you add the entries to your /etc/hosts file on the different desktop? And 
what error to you see?
Regards
Arul

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Pavithra R13
Sent: Wednesday, June 13, 2018 2:47 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] ONAP Portal access from outside

Hi All,

I have installed Kubernetes based ONAP Amsterdam this week on a Ubuntu server. 
I am able to access the Portal and the SDC/VID/Policy components from the ONAP 
Ubuntu server. But when I try to access the portal from a different desktop 
which is in the same subnet of ONAP server , I am able to access only the ONAP 
portal ,the other components are not accessible . Kindly let me know how to 
access the portal components from other servers.

Note: I have made host entry of the portal apps container and other containers 
in ONAP server and portal container . I am accessing the portal directly using 
portal apps container and not through VNC portal.

Please find attached screenshot for the portal pods.

Regards
Pavithra R
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] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Arash Hekmat]

Hi MultiCloud Team,

My 2 cents here.

I believe if below conditions are true, the K8S plugin can be implemented in Go 
or any other language. But if they are not true, it should probably match 
MultiCould’s core and use Python, for all the maintainability and integration 
concerns already raised.

The K8S plugin can use Go or any other language if:


  1.  It has its own separate git repo
  2.  It runs in its own separate docker container
  3.  It does not directly call or share MultiCould’s Python framework

Arash

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Wednesday, June 13, 2018 2:02 AM
To: Yang, Bin ; ADDEPALLI, SRINIVASA 
; MORALES RUVALCABA, VICTOR 
; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua ; Huang, Yun 

Subject: Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: 
[coe] Team meeting Agenda

If I understand correctly, there are 2 types of concerns regarding Go language 
(v.s. Python) here:

  *   Implementation, integration and testing: e.g. CI/CD integration, reuse of 
shared services etc.
  *   Long-term community support with the appropriate expertise in Go language.

The 2nd one, i.e long-term community support is actually the biggest concern. 
For example, after K8S plugin is developed with Go language, but the original 
Go developer no longer works in ONAP, do we have a pool of Go developers in 
ONAP community that can comfortably take over the work of maintenance and 
further evolving K8S Plugin? Or will then-current developers have to re-develop 
K8S Plugin with Python or Java because most of ONAP developers are Python or 
Java developers?

If there are very few Go developers in ONAP community, using Go language 
certainly brings huge risk of continuous support, maintenance and evolution in 
the future.

My 2 cents
Thanks
Bin

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: ADDEPALLI, SRINIVASA 
mailto:srinivasa.r.addepa...@intel.com>>; 
MORALES RUVALCABA, VICTOR 
mailto:victor.mora...@intel.com>>; 
onap-discuss@lists.onap.org; HU, BIN 
mailto:bh5...@att.com>>
Cc: Huang, Yun mailto:yun.hu...@windriver.com>>; 
HUANG, HAIBIN mailto:haibin.hu...@intel.com>>; Zhang, 
Xiaohua mailto:xiaohua.zh...@windriver.com>>
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the architecture perspective it is irrelevant w.r.t. 
how to implement the plugin service, hence up to developers/contributors’ 
choice. However, it is worth to think again for following reasons:

1, Leverage and Scale
   Aligning to existing practice of multicloud plugin 
implementation enables developers focus on the core value of the plugin, e.g. 
mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As 
part of ONAP projects it is required that the multicloud k8s plugin be 
integrated with CI/CD process and other shared services (e.g. AAF, centralized 
logging, etc.)  Right now CI/CD support projects with python binding very well, 
and the logging AOP facility for Python is well supported, I don’t know if 
there is off-the-shelf utility for golang available yet. If multicloud k8s 
plugin align to the existing practice of openstack plugin and vio plugin, then 
you don’t have to invest further time/cost on those effort.


2, Facilitate more participation from current multicloud committers/contributors
   multicloud committers/contributors has been working on python 
already for a long time , and it is not surprising that many of them are 
willing to participate/contribute to this multicloud k8s plugin development. 
Assuming that Golang is not as widely adopted as Python so most of them is not 
that familiar with Golang compared to Python, it would lower the barrier for 
them to contribute if multicloud k8s plugin could adopt the same language and 
framework.

3, Decrease the maintenance cost from either community and the Service 
Providers who will productize ONAP
   By align to the same practice and share the same building blocks 
across multicloud plugins, one committer/contributor support/maintain one 
plugin could also be possible to support another one with low cost to 
learn/understand it. This will decrease the TCO which is always a pain of open 
source product compared to those commercialized close source product.

4, facilitate pairwise/integration testing for fast release cadence
   It might not concern those architect, but it is really a pain 
for developers who support the pairwise/integration testing. Fortunately, 
python make our life better since it is possible to fix the bug on runtime and 
test it immediately, 

Re: [onap-discuss] How to clear logs

[Mandeep Khinda]

Hi,
It is a good question as I have had my disk filled before too.

I have removed the massive .json log file from /var/lib/docker/containers/*/* 
in the past after stopping the container and docker daemon but I would not 
suggest unless you were okay with having to re-deploy the pod as I have had 
mixed success.

I think we need to add some documentation to the K8s cluster build requirements 
to enable some sort of log rotation for the docker containers.
I found this:
https://kubernetes.io/docs/concepts/cluster-administration/logging/

Kubernetes currently is not responsible for rotating logs, but rather a 
deployment tool should set up a solution to address that. For example, in 
Kubernetes clusters, deployed by the kube-up.sh script, there is a 
logrotate tool configured to run each 
hour

By default, the docker daemon uses json-file as its logging driver and this 
thing comes out of the box with an unlimited size.

https://docs.docker.com/config/containers/logging/json-file/#usage

Try setting “--log-opt max-size=[SIZE]m” in your k8s nodes where docker is 
running to prevent this from happening again.

Thanks,
Mandeep

From:  on behalf of 
"abdelmuhaimen.sea...@orange.com" 
Date: Wednesday, June 13, 2018 at 2:09 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] How to clear logs

Hi,

I was able to resolve an issue with an ONAP OOM Pod that resulted in a log file 
filling up 95% of the disk space.

Now, what if I need to clear the logs of an ONAP OOM pod ? What is the correct 
process ?

Thanks.

Abdelmuhaimen Seaudi
Orange Labs Egypt
Email: abdelmuhaimen.sea...@orange.com
Mobile: +2012 84644 733


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
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] Trouble in VNF Onboarding

[FREEMAN, BRIAN D]

Did you populate AAI with the cloud information via robot's demo.sh init ?

Brina


From: onap-discuss-boun...@lists.onap.org  
On Behalf Of Shubhada Ramkrishna Vaze
Sent: Wednesday, June 13, 2018 9:30 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Trouble in VNF Onboarding

Hi,

We are trying to Onboard VNF and Instantiate the service.

We have followed below steps given in the wiki 
(https://wiki.onap.org/pages/viewpage.action?pageId=1018474<(https:/wiki.onap.org/pages/viewpage.action?pageId=1018474>)
1)Creating a new license model

2)Onboarding a new Virtual Function which uses the licensing model

3)Distributing a new VSP based on the VF

4)Deploy Service Instance in VID 
(https://wiki.onap.org/display/DW/Tutorial%3A+Creating+a+Service+Instance+from+a+Design+Model)
 a)Create Service Instance
  b) Add a Virtual Network Function under the Service Instance in VID

Till Service Instance Creation, we are able to follow the all steps 
successfully.

But we are facing issue while trying to add VNF under the service instance. For 
LCP region nothing is getting populated in the dropdown.

Could you please suggest us what needs to be done to resolve this issue?

PFB the screenshot for the same:

[cid:image001.png@01D40327.A789A290]


Thanks & Regards,
Shubhada


Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at 
http://www.techmahindra.com/Disclaimer.html
 externally 
http://tim.techmahindra.com/tim/disclaimer.html
 internally within TechMahindra.

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

[onap-discuss] Fwd: [integration][oof] SB01 still in use?

[Shankaranarayanan P N]

Hi Gary,

Our team is currently working on trying to wrap up some testing on the HPA
and multicloud front with the vCPE use case on multiple cloud instances.

While we were using SB01 initially, At the end of the Beijing release
cycle, Kang had requested us to set things up on SB07 as well. I’m not sure
which of the two is being currently used for the multiple cloud testing.

Arun/Ritu/Marcus, Which one of the two do we need?

Thanks,
Shankar

On Wed, Jun 13, 2018 at 8:20 AM Gary Wu  wrote:

> Hi OOF team,
>
> Are you still using Wind River Integration-SB-01?  If not, we’d like to
> shut down the instance and repurpose the environment.
>
> I’ll proceed with tearing down the instance If I don’t hear any responses
> back by noon PDT today.
>
> Thanks,
> Gary
>
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Trouble in VNF Onboarding

[Shubhada Ramkrishna Vaze]

Hi,

We are trying to Onboard VNF and Instantiate the service.

We have followed below steps given in the wiki 
(https://wiki.onap.org/pages/viewpage.action?pageId=1018474<(https:/wiki.onap.org/pages/viewpage.action?pageId=1018474>)
1)Creating a new license model

2)Onboarding a new Virtual Function which uses the licensing model

3)Distributing a new VSP based on the VF

4)Deploy Service Instance in VID 
(https://wiki.onap.org/display/DW/Tutorial%3A+Creating+a+Service+Instance+from+a+Design+Model)
 a)Create Service Instance
  b) Add a Virtual Network Function under the Service Instance in VID

Till Service Instance Creation, we are able to follow the all steps 
successfully.

But we are facing issue while trying to add VNF under the service instance. For 
LCP region nothing is getting populated in the dropdown.

Could you please suggest us what needs to be done to resolve this issue?

PFB the screenshot for the same:

[cid:image001.png@01D40327.A789A290]

Thanks & Regards,
Shubhada



Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html 
 externally 
http://tim.techmahindra.com/tim/disclaimer.html 
 internally within 
TechMahindra.


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

Re: [onap-discuss] ONAP Portal access from outside

[Mandeep Khinda]

Hi,
In ONAP Amsterdam using OOM, supported ONAP portal is access is through the VNC 
utility pod.  Direct access was introduced in OOM Beijing.

I am sure there are ways to get direct access either by a new approach or by 
backporting what was done in Beijing.  It also depends on what you did to get 
direct access in Amsterdam using Kubernetes.

I think the problem you are facing is that the widget applications loaded by 
the portal are not being exposed externally or are not reachable by your client 
that is on the same subnet.  That is configured in the portal database for each 
application.  I believe you can view/edit this in the portal GUI under 
application or widget configuration.
There is a URL and port for backend and frontend widgets that also would need 
to be reachable by your client and not just the main portal front end.  The 
port will need to be a nodePort and in Amsterdam I don’t believe they are 
because within the VNC pod the internal ports are resolvable.

Thanks,
Mandeep

From:  on behalf of Pavithra R13 

Date: Wednesday, June 13, 2018 at 2:49 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] ONAP Portal access from outside

Hi All,

I have installed Kubernetes based ONAP Amsterdam this week on a Ubuntu server. 
I am able to access the Portal and the SDC/VID/Policy components from the ONAP 
Ubuntu server. But when I try to access the portal from a different desktop 
which is in the same subnet of ONAP server , I am able to access only the ONAP 
portal ,the other components are not accessible . Kindly let me know how to 
access the portal components from other servers.

Note: I have made host entry of the portal apps container and other containers 
in ONAP server and portal container . I am accessing the portal directly using 
portal apps container and not through VNC portal.

Please find attached screenshot for the portal pods.

Regards
Pavithra R
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] [modeling] Papyrus Training Session - Reminder and Bridge

[jessie jewitt]

Hello-
This is a reminder that the Papyrus training session will take place
today at
9am Eastern time. Bridge info:

https://zoom.us/j/746737796

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

[onap-discuss] [integration][oof] SB01 still in use?

[Gary Wu]

Hi OOF team,

Are you still using Wind River Integration-SB-01?  If not, we'd like to shut 
down the instance and repurpose the environment.

I'll proceed with tearing down the instance If I don't hear any responses back 
by noon PDT today.

Thanks,
Gary


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

Re: [onap-discuss] policy-nexus in CrashLoopBackOff

[Santi Rodríguez]

Thank you Borislav for your response.

It worked perfect!

BR, Santiago

*Santiago Rodríguez García* | Senior Analyst
T/ + 34 986 410 091 (ext) 227
www.optaresolutions.com
[image: Optare Solutions] 

2018-06-13 13:15 GMT+02:00 Borislav Glozman :

> Hi Santiago,
>
>
>
> Nexus liveliness timeout is too short, it doesn’t manage to start during
> it.
>
> I am opening a defect in OOM to increase the timeout:
>
> OOM-1139  - *Policy Nexus liveness
> initialDelaySeconds is too short*
>
>
>
> Meanwhile you can change
>
> policy/charts/drools/charts/nexus/values.yaml
>
> Increase both initialDelaySeconds to 180 and redeploy policy.
>
> Do not forget to do “make all”…
>
>
>
>
>
> Thanks,
>
> Borislav Glozman
>
> O:+972.9.776.1988
>
> M:+972.52.2835726
>
> [image: amdocs-a]
>
> *Amdocs a **Platinum member of ONAP*
> 
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Santi Rodríguez
> *Sent:* Wednesday, June 13, 2018 12:02 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] policy-nexus in CrashLoopBackOff
>
>
>
> Hi all,
>
>
>
> The policy component always worked fine for me but now the policy-nexus
> pod is in CrashLoopBackOff state.
>
>
>
> With the "kubectl describe pod" command I can see the next info:
>
>
>
>   Warning  Unhealthy  5m (x5 over 6m)  kubelet, chubunteado  
> *Liveness
> probe failed: dial tcp 10.42.179.225:8081 :
> getsockopt: connection refused*
>   Normal   Pulled 5m (x3 over 7m)  kubelet, chubunteado
> Container image "nexus3.onap.org:10001/sonatype/nexus:2.14.8-01" already
> present on machine
>   Normal   Killing5m (x2 over 6m)  kubelet, chubunteado  
> *Killing
> container with id docker://nexus:Container failed liveness probe..
> Container will be killed and recreated*.
>
>
>
> The log:
>
>
>
> -
>
> Initializing Nexus Repository Manager OSS 2.14.8-01
>
> -
> 2018-06-13 08:52:57,070+ INFO  [jetty-main-1]  
> org.sonatype.nexus.NxApplication
> - Activating locally installed plugins...
> 2018-06-13 08:52:58,457+ INFO  [jetty-main-1]
> com.sun.jersey.server.impl.application.WebApplicationImpl - Initiating
> Jersey application, version 'Jersey: 1.17.1 02/28/2013 12:47 PM'
> 2018-06-13 08:53:01,341+ INFO  [jetty-main-1]
> org.sonatype.nexus.plugins.bcprov.CryptoPlugin - Unlimited strength JCE
> policy detected
> 2018-06-13 08:53:02,312+ INFO  [jetty-main-1]
> org.sonatype.nexus.kazuki.KazukiPlugin - Kazuki version: 0.1.8
> 2018-06-13 08:53:10,753+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.ShadowRepository:nuget-shadow).
> 2018-06-13 08:53:10,759+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.GroupRepository:nuget-group).
> 2018-06-13 08:53:10,759+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.Repository:nuget-proxy).
> 2018-06-13 08:53:11,015+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.GroupRepository:npm-group).
> 2018-06-13 08:53:11,016+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.Repository:npm-proxy).
> 2018-06-13 08:53:11,016+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.Repository:npm-hosted).
> 2018-06-13 08:53:12,796+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.GroupRepository:rubygems-group).
> 2018-06-13 08:53:12,802+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.Repository:rubygems-proxy).
> 2018-06-13 08:53:12,802+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type RepositoryType=(org.sonatype.
> nexus.proxy.repository.Repository:rubygems-hosted).
> 2018-06-13 08:53:16,266+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type 

Re: [onap-discuss] policy-nexus in CrashLoopBackOff

[Borislav Glozman]

Hi Santiago,

Nexus liveliness timeout is too short, it doesn’t manage to start during it.
I am opening a defect in OOM to increase the timeout:
OOM-1139 - Policy Nexus liveness 
initialDelaySeconds is too short

Meanwhile you can change
policy/charts/drools/charts/nexus/values.yaml
Increase both initialDelaySeconds to 180 and redeploy policy.
Do not forget to do “make all”…


Thanks,
Borislav Glozman
O:+972.9.776.1988
M:+972.52.2835726
[amdocs-a]
Amdocs a Platinum member of 
ONAP

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Santi Rodríguez
Sent: Wednesday, June 13, 2018 12:02 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] policy-nexus in CrashLoopBackOff

Hi all,

The policy component always worked fine for me but now the policy-nexus pod is 
in CrashLoopBackOff state.

With the "kubectl describe pod" command I can see the next info:

  Warning  Unhealthy  5m (x5 over 6m)  kubelet, chubunteado  
Liveness probe failed: dial tcp 10.42.179.225:8081: 
getsockopt: connection refused
  Normal   Pulled 5m (x3 over 7m)  kubelet, chubunteado  
Container image 
"nexus3.onap.org:10001/sonatype/nexus:2.14.8-01"
 already present on machine
  Normal   Killing5m (x2 over 6m)  kubelet, chubunteado  
Killing container with id docker://nexus:Container failed liveness probe.. 
Container will be killed and recreated.

The log:

-

Initializing Nexus Repository Manager OSS 2.14.8-01

-
2018-06-13 08:52:57,070+ INFO  [jetty-main-1]  
org.sonatype.nexus.NxApplication - Activating locally installed plugins...
2018-06-13 08:52:58,457+ INFO  [jetty-main-1]  
com.sun.jersey.server.impl.application.WebApplicationImpl - Initiating Jersey 
application, version 'Jersey: 1.17.1 02/28/2013 12:47 PM'
2018-06-13 08:53:01,341+ INFO  [jetty-main-1]  
org.sonatype.nexus.plugins.bcprov.CryptoPlugin - Unlimited strength JCE policy 
detected
2018-06-13 08:53:02,312+ INFO  [jetty-main-1]  
org.sonatype.nexus.kazuki.KazukiPlugin - Kazuki version: 0.1.8
2018-06-13 08:53:10,753+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.ShadowRepository:nuget-shadow).
2018-06-13 08:53:10,759+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:nuget-group).
2018-06-13 08:53:10,759+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:nuget-proxy).
2018-06-13 08:53:11,015+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:npm-group).
2018-06-13 08:53:11,016+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:npm-proxy).
2018-06-13 08:53:11,016+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:npm-hosted).
2018-06-13 08:53:12,796+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:rubygems-group).
2018-06-13 08:53:12,802+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:rubygems-proxy).
2018-06-13 08:53:12,802+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:rubygems-hosted).
2018-06-13 08:53:16,266+ INFO  [jetty-main-1]  
org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry - Registered 
Repository type 
RepositoryType=(org.sonatype.nexus.proxy.repository.WebSiteRepository:site).
2018-06-13 08:53:17,984+ INFO  [jetty-main-1]  
org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on plugin 
"org.sonatype.nexus.plugins:nexus-rutauth-plugin:2.14.8-01" was successful.
2018-06-13 08:53:17,986+ INFO  [jetty-main-1]  
org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on plugin 

[onap-discuss] policy-nexus in CrashLoopBackOff

[Santi Rodríguez]

Hi all,

The policy component always worked fine for me but now the policy-nexus pod
is in CrashLoopBackOff state.

With the "kubectl describe pod" command I can see the next info:

  Warning  Unhealthy  5m (x5 over 6m)  kubelet,
chubunteado  *Liveness
probe failed: dial tcp 10.42.179.225:8081 :
getsockopt: connection refused*
  Normal   Pulled 5m (x3 over 7m)  kubelet, chubunteado
Container image "nexus3.onap.org:10001/sonatype/nexus:2.14.8-01" already
present on machine
  Normal   Killing5m (x2 over 6m)  kubelet,
chubunteado  *Killing
container with id docker://nexus:Container failed liveness probe..
Container will be killed and recreated*.


The log:

-
>
> Initializing Nexus Repository Manager OSS 2.14.8-01
>
> -
> 2018-06-13 08:52:57,070+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Activating locally installed plugins...
> 2018-06-13 08:52:58,457+ INFO  [jetty-main-1]
> com.sun.jersey.server.impl.application.WebApplicationImpl - Initiating
> Jersey application, version 'Jersey: 1.17.1 02/28/2013 12:47 PM'
> 2018-06-13 08:53:01,341+ INFO  [jetty-main-1]
> org.sonatype.nexus.plugins.bcprov.CryptoPlugin - Unlimited strength JCE
> policy detected
> 2018-06-13 08:53:02,312+ INFO  [jetty-main-1]
> org.sonatype.nexus.kazuki.KazukiPlugin - Kazuki version: 0.1.8
> 2018-06-13 08:53:10,753+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.ShadowRepository:nuget-shadow).
> 2018-06-13 08:53:10,759+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:nuget-group).
> 2018-06-13 08:53:10,759+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:nuget-proxy).
> 2018-06-13 08:53:11,015+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:npm-group).
> 2018-06-13 08:53:11,016+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:npm-proxy).
> 2018-06-13 08:53:11,016+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:npm-hosted).
> 2018-06-13 08:53:12,796+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.GroupRepository:rubygems-group).
> 2018-06-13 08:53:12,802+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:rubygems-proxy).
> 2018-06-13 08:53:12,802+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.Repository:rubygems-hosted).
> 2018-06-13 08:53:16,266+ INFO  [jetty-main-1]
> org.sonatype.nexus.proxy.registry.DefaultRepositoryTypeRegistry -
> Registered Repository type
> RepositoryType=(org.sonatype.nexus.proxy.repository.WebSiteRepository:site).
> 2018-06-13 08:53:17,984+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin "org.sonatype.nexus.plugins:nexus-rutauth-plugin:2.14.8-01" was
> successful.
> 2018-06-13 08:53:17,986+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin "org.sonatype.nexus.plugins:nexus-restlet1x-plugin:2.14.8-01" was
> successful.
> 2018-06-13 08:53:17,986+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin "org.sonatype.nexus.plugins:nexus-webresources-plugin:2.14.8-01" was
> successful.
> 2018-06-13 08:53:17,986+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin "org.sonatype.nexus.plugins:nexus-wonderland-plugin:2.14.8-01" was
> successful.
> 2018-06-13 08:53:17,987+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin "org.sonatype.nexus.plugins:nexus-maven-bridge-plugin:2.14.8-01" was
> successful.
> 2018-06-13 08:53:17,987+ INFO  [jetty-main-1]
> org.sonatype.nexus.NxApplication - Plugin manager request "ACTIVATE" on
> plugin 

Re: [onap-discuss] [aai][integration] Bad image tags

[eric.debeau]

Hello Helen

I simply follow the official documentation ;-) and deploy on our lab with no 
pre-installed Docker images.

And Jimmy agreed there is a problem in the deploy_vm1.sh script
Cf https://lists.onap.org/pipermail/onap-discuss/2018-June/010250.html


With the associated JIRA ticket https://jira.onap.org/browse/AAI-1222

I suspect that it ok on WindRiver platform because you have the right Docker 
images downloaded from previous installation.

In addition, you are also using the following Docker  repo: 10.12.5.2:5000 
according to
https://git.onap.org/integration/tree/test/ete/labs/windriver/onap-openstack-template.env

Best Regards

Eric

De : Yunxia Chen [mailto:helen.c...@huawei.com]
Envoyé : mercredi 13 juin 2018 01:08
À : DEBEAU Eric IMT/OLN; onap-discuss@lists.onap.org; Gary Wu
Objet : Re: [onap-discuss] [aai][integration] Bad image tags

Hi, Eric,
Could you please show us what’s the command you use to get this? Gary did some 
sanity testing with this env, it seems fine:

http://12.234.32.117/jenkins/job/windriver-beijing-heat-deploy/

Regards,

Helen Chen

From:  on behalf of Eric Debeau 

Date: Tuesday, June 12, 2018 at 5:17 AM
To: onap-discuss 
Subject: [onap-discuss] [aai][integration] Bad image tags

Hello

We tested the fresh new installation using Heat and the 2.0.0-ONAP branch


For AAI, we have some pbs due to the bad image tags. The init script fetches 
docker image with tag 1.2.2

Pulling repository nexus3.onap.org:10001/onap/model-loader
Tag 1.2.2 not found in repository nexus3.onap.org:10001/onap/model-loader
Error response from daemon: No such image: 
nexus3.onap.org:10001/onap/model-loader:1.2.2
Pulling repository nexus3.onap.org:10001/onap/sparky-be
Tag 1.2.2 not found in repository nexus3.onap.org:10001/onap/sparky-be
Error response from daemon: No such image: 
nexus3.onap.org:10001/onap/sparky-be:1.2.2
Pulling repository nexus3.onap.org:10001/onap/champ
Error: image onap/champ:1.2.2 not found
Error response from daemon: No such image: 
nexus3.onap.org:10001/onap/champ:1.2.2
Pulling repository nexus3.onap.org:10001/onap/gizmo
Error: image onap/gizmo:1.2.2 not found
Error response from daemon: No such image: 
nexus3.onap.org:10001/onap/gizmo:1.2.2
Pulling repository nexus3.onap.org:10001/onap/babel
Error: image onap/babel:1.2.2 not found
Error response from daemon: No such image: 
nexus3.onap.org:10001/onap/babel:1.2.2

These tags are not aligned with the manifest
https://onap.readthedocs.io/en/beijing/release/release-manifest.html#doc-release-manifest

As a result, it is not possible to download the docker images. We must do it 
manually with the right tag.

I believe that we must update the script deploy_vm1.sh to get the right tag 
values

Best regards

Eric

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[onap-discuss] How to clear logs

[abdelmuhaimen.seaudi]

Hi,

I was able to resolve an issue with an ONAP OOM Pod that resulted in a log file 
filling up 95% of the disk space.

Now, what if I need to clear the logs of an ONAP OOM pod ? What is the correct 
process ?

Thanks.

Abdelmuhaimen Seaudi
Orange Labs Egypt
Email: abdelmuhaimen.sea...@orange.com
Mobile: +2012 84644 733


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[HU, BIN]

If I understand correctly, there are 2 types of concerns regarding Go language 
(v.s. Python) here:

-  Implementation, integration and testing: e.g. CI/CD integration, 
reuse of shared services etc.

-  Long-term community support with the appropriate expertise in Go 
language.

The 2nd one, i.e long-term community support is actually the biggest concern. 
For example, after K8S plugin is developed with Go language, but the original 
Go developer no longer works in ONAP, do we have a pool of Go developers in 
ONAP community that can comfortably take over the work of maintenance and 
further evolving K8S Plugin? Or will then-current developers have to re-develop 
K8S Plugin with Python or Java because most of ONAP developers are Python or 
Java developers?

If there are very few Go developers in ONAP community, using Go language 
certainly brings huge risk of continuous support, maintenance and evolution in 
the future.

My 2 cents
Thanks
Bin

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: ADDEPALLI, SRINIVASA ; MORALES RUVALCABA, 
VICTOR ; onap-discuss@lists.onap.org; HU, BIN 

Cc: Huang, Yun ; HUANG, HAIBIN 
; Zhang, Xiaohua 
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 
Agenda

Hi Victor, Srini and all,

In addition to the agenda you listed, could you also add one more to touch the 
topic of building blocks (e.g. “language binding” with golang instead of 
python) for multicloud k8s plugin?

I do understand that from the architecture perspective it is irrelevant w.r.t. 
how to implement the plugin service, hence up to developers/contributors’ 
choice. However, it is worth to think again for following reasons:

1, Leverage and Scale
   Aligning to existing practice of multicloud plugin 
implementation enables developers focus on the core value of the plugin, e.g. 
mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As 
part of ONAP projects it is required that the multicloud k8s plugin be 
integrated with CI/CD process and other shared services (e.g. AAF, centralized 
logging, etc.)  Right now CI/CD support projects with python binding very well, 
and the logging AOP facility for Python is well supported, I don’t know if 
there is off-the-shelf utility for golang available yet. If multicloud k8s 
plugin align to the existing practice of openstack plugin and vio plugin, then 
you don’t have to invest further time/cost on those effort.


2, Facilitate more participation from current multicloud committers/contributors
   multicloud committers/contributors has been working on python 
already for a long time , and it is not surprising that many of them are 
willing to participate/contribute to this multicloud k8s plugin development. 
Assuming that Golang is not as widely adopted as Python so most of them is not 
that familiar with Golang compared to Python, it would lower the barrier for 
them to contribute if multicloud k8s plugin could adopt the same language and 
framework.

3, Decrease the maintenance cost from either community and the Service 
Providers who will productize ONAP
   By align to the same practice and share the same building blocks 
across multicloud plugins, one committer/contributor support/maintain one 
plugin could also be possible to support another one with low cost to 
learn/understand it. This will decrease the TCO which is always a pain of open 
source product compared to those commercialized close source product.

4, facilitate pairwise/integration testing for fast release cadence
   It might not concern those architect, but it is really a pain 
for developers who support the pairwise/integration testing. Fortunately, 
python make our life better since it is possible to fix the bug on runtime and 
test it immediately, which reduce the cycle of debugging. I can share you some 
feedback from several PTLs whom I had supported during Pairwise/integration 
test if you are interested to know.

So it is my 2 cents, please let me know if you have other concerns/opinions and 
I am willing to learn them, 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: Wednesday, June 13, 2018 9:21 AM
To: ADDEPALLI, SRINIVASA; MORALES RUVALCABA, VICTOR; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [coe] Team meeting Agenda

Hi Srini, and all,

   With regarding to the “each deployment instance needs to be 
uniquely identified”,  what is the intention for this “uniquely identified”? I 
mean, who will care about/consume this unique ID?

IMHO, from multicloud NBI consumers’ perspective, I don’t get the point to