Re: [onap-discuss] ONAP on Kubernetes

2018-04-16 Thread Roger Maitland
Hi A. Seaudi,

I’m really only speculating here but if there was a resource leak (memory or 
storage) that consumes everything on a node (physical machine or VM) the 
containers on that node will fail and Kubernetes will try to restart them. If 
there are insufficient resources the pod(s) will remain in “init” status until 
there are sufficient resources (say by adding a new node to the Kubernetes 
cluster).

The Beijing release is in the integration phase now and one of the major goals 
of the release was to achieve stability.  It would be great if you were willing 
to switch your testing to Beijing so we can identify problems like resource 
leaks quickly.  We want Beijing to be production ready so the more hardening we 
do the better.

Cheers,
Roger

From: "abdelmuhaimen.sea...@orange.com" 
Date: Saturday, April 14, 2018 at 1:00 PM
To: Michael O'Brien , Roger Maitland 
, "onap-discuss@lists.onap.org" 

Subject: RE: [onap-discuss] ONAP on Kubernetes

Hi, I started with another clean vm, and now OOM is running fine.

However, I am interested to know why many pods return to "init" status after 
one or two days running.

Thanks

A. Seaudi

From: SEAUDI Abdelmuhaimen OBS/CSO
Sent: Saturday, April 14, 2018 3:11 PM
To: Michael O'Brien; Roger Maitland; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes
Hi,

I was able to clean my system and close down port 10250, and the cpu issue is 
now resolved.

However, after a day or 2 runnnig OOM, i find many of the pods are now in init 
status, and i need to "./deleteAll -n onap -a aai" for example, and 
"./createAll -n onap -a aai" again to resume the pods working.

I worked like that for a while, but now i am facing errors similar to below, 
and i cannot get the pods to run again.

onap-message-router   dmaap-3126594942-cfm9n 0/1   rpc 
error: code = 2 desc = failed to start container 
"74b8d5d04b693c432a4b21a03c272418451eccdc54305330d998bfee0d532a59
": Error response from daemon: {"message":"invalid header field value \"oci 
runtime error: container_linux.go:247: starting container process caused 
\\\"process_linux.go:359: container init
 caused \\\"rootfs_linux.go:53: mounting 
\\\"/dockerdata-nfs/onap/message-router/dmaap/cadi.properties\\\"
 to rootfs \\\"/var/lib/docker/aufs/mnt/737
6ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b\\\" 
at 
\\\"/var/lib/docker/aufs/mnt/7376ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b/ap
pl/dmaapMR1/etc/cadi.properties\\\" caused \\\"not a 
directory\\\"\\\"\\\"\\n\""}   3  1m

Any idea what this error means ?

I tried to use a clean vm and pulling 
https://jira.onap.org/secure/attachment/11421/oom_rancher_setup.sh and 
https://jira.onap.org/secure/attachment/11413/cd.sh but i get the same result.

Thanks

A. Seaudi

From: Michael O'Brien [frank.obr...@amdocs.com]
Sent: Monday, March 26, 2018 8:34 PM
To: Roger Maitland; SEAUDI Abdelmuhaimen OBS/CSO; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes
Abdul,
  Hi, if you are at 95-100% constantly – that will not be ONAP – even on an 8 
vCore you will see a max of 50-90% - if you see 95-100 – then it is 
https://jira.onap.org/browse/OOM-806   - and if your network is public facing – 
as Roger says – lock down ports 10249-10255, do a “top” first, hit c and verify 
you are compromised.
  Use the port lockdown ACL in the Azure template as a guide below
https://gerrit.onap.org/r/#/c/33527/9/install/azure/arm_deploy_ons_sut.json

   For the full HD – you should be able to run for weeks  - I have a 120G drive.
   For reference amsterdam will not breach 64G – you should hover between 51 
and 55. – Beijing has this issue periodically because the odd container will 
consume 10G – we are working on limiting the profile for an individual 
container – out of the box each container thinks it has the whole VM.

   thank you
   /michael

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland
Sent: Monday, March 26, 2018 09:55
To: abdelmuhaimen.sea...@orange.com; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes

I suspect you’ve come across two, possibly three, different issues:

  *   Memory leaks within the containers of (potentially) several projects:  
There already are several Jira bugs open against suspected memory leaks: 
SDC-1092<https://jira.onap.org/browse/SDC-1092>, 
DCAEGEN2-198<https://jira.onap.org/browse/DCAEGEN2-198>, 
PORTAL-211<https://jira.onap.org/browse/PORTAL-211>, and 
VID-196<https://jira.onap.org/browse/VID-196>.  If you’ve found mem

Re: [onap-discuss] ONAP on Kubernetes

2018-04-14 Thread abdelmuhaimen.seaudi
Hi, I started with another clean vm, and now OOM is running fine.

However, I am interested to know why many pods return to "init" status after 
one or two days running.

Thanks

A. Seaudi

From: SEAUDI Abdelmuhaimen OBS/CSO
Sent: Saturday, April 14, 2018 3:11 PM
To: Michael O'Brien; Roger Maitland; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes

Hi,

I was able to clean my system and close down port 10250, and the cpu issue is 
now resolved.

However, after a day or 2 runnnig OOM, i find many of the pods are now in init 
status, and i need to "./deleteAll -n onap -a aai" for example, and 
"./createAll -n onap -a aai" again to resume the pods working.

I worked like that for a while, but now i am facing errors similar to below, 
and i cannot get the pods to run again.

onap-message-router   dmaap-3126594942-cfm9n 0/1   rpc 
error: code = 2 desc = failed to start container 
"74b8d5d04b693c432a4b21a03c272418451eccdc54305330d998bfee0d532a59
": Error response from daemon: {"message":"invalid header field value \"oci 
runtime error: container_linux.go:247: starting container process caused 
\\\"process_linux.go:359: container init
 caused \\\"rootfs_linux.go:53: mounting 
\\\"/dockerdata-nfs/onap/message-router/dmaap/cadi.properties\\\"
 to rootfs \\\"/var/lib/docker/aufs/mnt/737
6ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b\\\" 
at 
\\\"/var/lib/docker/aufs/mnt/7376ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b/ap
pl/dmaapMR1/etc/cadi.properties\\\" caused \\\"not a 
directory\\\"\\\"\\\"\\n\""}   3  1m

Any idea what this error means ?

I tried to use a clean vm and pulling 
https://jira.onap.org/secure/attachment/11421/oom_rancher_setup.sh and 
https://jira.onap.org/secure/attachment/11413/cd.sh but i get the same result.

Thanks

A. Seaudi

From: Michael O'Brien [frank.obr...@amdocs.com]
Sent: Monday, March 26, 2018 8:34 PM
To: Roger Maitland; SEAUDI Abdelmuhaimen OBS/CSO; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes

Abdul,
  Hi, if you are at 95-100% constantly – that will not be ONAP – even on an 8 
vCore you will see a max of 50-90% - if you see 95-100 – then it is 
https://jira.onap.org/browse/OOM-806   - and if your network is public facing – 
as Roger says – lock down ports 10249-10255, do a “top” first, hit c and verify 
you are compromised.
  Use the port lockdown ACL in the Azure template as a guide below
https://gerrit.onap.org/r/#/c/33527/9/install/azure/arm_deploy_ons_sut.json

   For the full HD – you should be able to run for weeks  - I have a 120G drive.
   For reference amsterdam will not breach 64G – you should hover between 51 
and 55. – Beijing has this issue periodically because the odd container will 
consume 10G – we are working on limiting the profile for an individual 
container – out of the box each container thinks it has the whole VM.

   thank you
   /michael

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland
Sent: Monday, March 26, 2018 09:55
To: abdelmuhaimen.sea...@orange.com; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes

I suspect you’ve come across two, possibly three, different issues:

  *   Memory leaks within the containers of (potentially) several projects:  
There already are several Jira bugs open against suspected memory leaks: 
SDC-1092<https://jira.onap.org/browse/SDC-1092>, 
DCAEGEN2-198<https://jira.onap.org/browse/DCAEGEN2-198>, 
PORTAL-211<https://jira.onap.org/browse/PORTAL-211>, and 
VID-196<https://jira.onap.org/browse/VID-196>.  If you’ve found memory leaks 
outside of these components please raise a Jira bug against the appropriate 
project.  Note that stability is an important part of the Beijing release and 
many of the teams have reworked their components so hopefully the leaks have 
been addressed.  Please keep watch as the new code is made available.
  *   Likely log files are consuming all of the available storage.  Log 
rotation needs to be implemented across all of ONAP to ensure that the storage 
volumes aren’t consumed over time.  Again, if you can track the problem down to 
a specific component please raise a Jira bug.
  *   If your system is available to internet you may find that it is being 
used to mine bitcoin.  Unfortunately, some Kubernetes systems are being 
attacked this way so you’ll want to watch your system closely.  The ONAP team 
is working to address this issue.

Thank you for your observations – this is how we make ONAP production grade.

Cheers,
Roger

From: 
mailto:onap-discuss-boun...@l

Re: [onap-discuss] ONAP on Kubernetes

2018-04-14 Thread abdelmuhaimen.seaudi
Hi,

I was able to clean my system and close down port 10250, and the cpu issue is 
now resolved.

However, after a day or 2 runnnig OOM, i find many of the pods are now in init 
status, and i need to "./deleteAll -n onap -a aai" for example, and 
"./createAll -n onap -a aai" again to resume the pods working.

I worked like that for a while, but now i am facing errors similar to below, 
and i cannot get the pods to run again.

onap-message-router   dmaap-3126594942-cfm9n 0/1   rpc 
error: code = 2 desc = failed to start container 
"74b8d5d04b693c432a4b21a03c272418451eccdc54305330d998bfee0d532a59
": Error response from daemon: {"message":"invalid header field value \"oci 
runtime error: container_linux.go:247: starting container process caused 
\\\"process_linux.go:359: container init
 caused \\\"rootfs_linux.go:53: mounting 
\\\"/dockerdata-nfs/onap/message-router/dmaap/cadi.properties\\\"
 to rootfs \\\"/var/lib/docker/aufs/mnt/737
6ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b\\\" 
at 
\\\"/var/lib/docker/aufs/mnt/7376ab454562d2c60dccf7a0a24f3a14b7ee33461f50487b8da6e1b358f5511b/ap
pl/dmaapMR1/etc/cadi.properties\\\" caused \\\"not a 
directory\\\"\\\"\\\"\\n\""}   3  1m

Any idea what this error means ?

I tried to use a clean vm and pulling 
https://jira.onap.org/secure/attachment/11421/oom_rancher_setup.sh and 
https://jira.onap.org/secure/attachment/11413/cd.sh but i get the same result.

Thanks

A. Seaudi

From: Michael O'Brien [frank.obr...@amdocs.com]
Sent: Monday, March 26, 2018 8:34 PM
To: Roger Maitland; SEAUDI Abdelmuhaimen OBS/CSO; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes

Abdul,
  Hi, if you are at 95-100% constantly – that will not be ONAP – even on an 8 
vCore you will see a max of 50-90% - if you see 95-100 – then it is 
https://jira.onap.org/browse/OOM-806   - and if your network is public facing – 
as Roger says – lock down ports 10249-10255, do a “top” first, hit c and verify 
you are compromised.
  Use the port lockdown ACL in the Azure template as a guide below
https://gerrit.onap.org/r/#/c/33527/9/install/azure/arm_deploy_ons_sut.json

   For the full HD – you should be able to run for weeks  - I have a 120G drive.
   For reference amsterdam will not breach 64G – you should hover between 51 
and 55. – Beijing has this issue periodically because the odd container will 
consume 10G – we are working on limiting the profile for an individual 
container – out of the box each container thinks it has the whole VM.

   thank you
   /michael

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland
Sent: Monday, March 26, 2018 09:55
To: abdelmuhaimen.sea...@orange.com; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes

I suspect you’ve come across two, possibly three, different issues:

  *   Memory leaks within the containers of (potentially) several projects:  
There already are several Jira bugs open against suspected memory leaks: 
SDC-1092<https://jira.onap.org/browse/SDC-1092>, 
DCAEGEN2-198<https://jira.onap.org/browse/DCAEGEN2-198>, 
PORTAL-211<https://jira.onap.org/browse/PORTAL-211>, and 
VID-196<https://jira.onap.org/browse/VID-196>.  If you’ve found memory leaks 
outside of these components please raise a Jira bug against the appropriate 
project.  Note that stability is an important part of the Beijing release and 
many of the teams have reworked their components so hopefully the leaks have 
been addressed.  Please keep watch as the new code is made available.
  *   Likely log files are consuming all of the available storage.  Log 
rotation needs to be implemented across all of ONAP to ensure that the storage 
volumes aren’t consumed over time.  Again, if you can track the problem down to 
a specific component please raise a Jira bug.
  *   If your system is available to internet you may find that it is being 
used to mine bitcoin.  Unfortunately, some Kubernetes systems are being 
attacked this way so you’ll want to watch your system closely.  The ONAP team 
is working to address this issue.

Thank you for your observations – this is how we make ONAP production grade.

Cheers,
Roger

From: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of 
"abdelmuhaimen.sea...@orange.com<mailto:abdelmuhaimen.sea...@orange.com>>
Date: Saturday, March 24, 2018 at 5:54 AM
To: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>
Subject: [onap-discuss] ONAP on Kubernetes

Hi,

I deploy a minimum ONAP Amsterdam on Kubernetes, using a 64 GB RAM + 8 vCPU or 
16 vCPU.

The starting RAM utilization is ar

Re: [onap-discuss] ONAP on kubernetes

2018-03-26 Thread Michael O'Brien
We would need more details on your environment.
Running Rancher/kubadm
Running amsterdam/Beijing
Verify helm version
Verify kubernetes version
Verify kubectl version
Verify docker version
Verify Ubuntu version
Verify the routable IP or hostname entered in /etc/hosts - for rancher 
registration
Verify you created/purged the config pod properly
If running on master - know that there are two MSO's the old one and the new 
helm config based one
Verify your openstack version - use the intel openlab as a reference - private 
corporate openstacks  have a lot of varied/not-working configs like hybrid 
routers, nfs file systems with issues, over-subscription  Any of these can 
cause any part of your stack to hang.

Developers like us try to help each other out - if you figure out your issue 
and have a cause/effect/solution - please document it for others.

Thank you
/michael

From: ramya.ravichandr...@wipro.com [mailto:ramya.ravichandr...@wipro.com]
Sent: Monday, March 26, 2018 07:30
To: Michael O'Brien 
Subject: ONAP on kubernetes




Hi



This is ramya. I am currently working in ONAP. I have the ONAP environment set 
up on kubernetes, as given in the 
link,https://wiki.onap.org/display/DW/ONAP+on+Kubernetes.



I am facing a problem when trying to replace the MSO image, with my modified 
MSO docker image.

the creation is successful but when trying to delete the image using the command

" ./deleteAll.bash -n onap -a mso", the termination is stuck at waiting for 
namespaces termination.. and wont respond.



And then i am not able to use the setup again. is there any other way to 
terminate the running MSO container or to replace it . Kindly shed some light 
on this regard.




[http://marketing.wiprodigital.com/apps/wipro-esig/assets/images/logo-01.png]

Ramya Ravichandran

Project Engineer

NEPC


Wipro Limited





The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

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

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


Re: [onap-discuss] ONAP on Kubernetes

2018-03-26 Thread Michael O'Brien
Abdul,
  Hi, if you are at 95-100% constantly – that will not be ONAP – even on an 8 
vCore you will see a max of 50-90% - if you see 95-100 – then it is 
https://jira.onap.org/browse/OOM-806   - and if your network is public facing – 
as Roger says – lock down ports 10249-10255, do a “top” first, hit c and verify 
you are compromised.
  Use the port lockdown ACL in the Azure template as a guide below
https://gerrit.onap.org/r/#/c/33527/9/install/azure/arm_deploy_ons_sut.json

   For the full HD – you should be able to run for weeks  - I have a 120G drive.
   For reference amsterdam will not breach 64G – you should hover between 51 
and 55. – Beijing has this issue periodically because the odd container will 
consume 10G – we are working on limiting the profile for an individual 
container – out of the box each container thinks it has the whole VM.

   thank you
   /michael

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland
Sent: Monday, March 26, 2018 09:55
To: abdelmuhaimen.sea...@orange.com; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes

I suspect you’ve come across two, possibly three, different issues:

  *   Memory leaks within the containers of (potentially) several projects:  
There already are several Jira bugs open against suspected memory leaks: 
SDC-1092<https://jira.onap.org/browse/SDC-1092>, 
DCAEGEN2-198<https://jira.onap.org/browse/DCAEGEN2-198>, 
PORTAL-211<https://jira.onap.org/browse/PORTAL-211>, and 
VID-196<https://jira.onap.org/browse/VID-196>.  If you’ve found memory leaks 
outside of these components please raise a Jira bug against the appropriate 
project.  Note that stability is an important part of the Beijing release and 
many of the teams have reworked their components so hopefully the leaks have 
been addressed.  Please keep watch as the new code is made available.
  *   Likely log files are consuming all of the available storage.  Log 
rotation needs to be implemented across all of ONAP to ensure that the storage 
volumes aren’t consumed over time.  Again, if you can track the problem down to 
a specific component please raise a Jira bug.
  *   If your system is available to internet you may find that it is being 
used to mine bitcoin.  Unfortunately, some Kubernetes systems are being 
attacked this way so you’ll want to watch your system closely.  The ONAP team 
is working to address this issue.

Thank you for your observations – this is how we make ONAP production grade.

Cheers,
Roger

From: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of 
"abdelmuhaimen.sea...@orange.com<mailto:abdelmuhaimen.sea...@orange.com>" 
mailto:abdelmuhaimen.sea...@orange.com>>
Date: Saturday, March 24, 2018 at 5:54 AM
To: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" 
mailto:onap-discuss@lists.onap.org>>
Subject: [onap-discuss] ONAP on Kubernetes

Hi,

I deploy a minimum ONAP Amsterdam on Kubernetes, using a 64 GB RAM + 8 vCPU or 
16 vCPU.

The starting RAM utilization is around 30--40 GB RAM.

After one or two days, all the cpu cores reach 100%, and i reboot the VM, to be 
able to have some responsive feedback.

Sometimes, the HDD is full, and i have to reset the VM and redploy from scratch.

What is the reason for saturating all the CPU cores, or the RAM ?

Is there something I can do to minimize this behaviour ? should I use the 
Master Branch instead of Amsterdam ?

Thanks.

A. Seaudi

_



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
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

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

Re: [onap-discuss] ONAP on Kubernetes

2018-03-26 Thread Roger Maitland
I suspect you’ve come across two, possibly three, different issues:

  *   Memory leaks within the containers of (potentially) several projects:  
There already are several Jira bugs open against suspected memory leaks: 
SDC-1092, 
DCAEGEN2-198, 
PORTAL-211, and 
VID-196.  If you’ve found memory leaks 
outside of these components please raise a Jira bug against the appropriate 
project.  Note that stability is an important part of the Beijing release and 
many of the teams have reworked their components so hopefully the leaks have 
been addressed.  Please keep watch as the new code is made available.
  *   Likely log files are consuming all of the available storage.  Log 
rotation needs to be implemented across all of ONAP to ensure that the storage 
volumes aren’t consumed over time.  Again, if you can track the problem down to 
a specific component please raise a Jira bug.
  *   If your system is available to internet you may find that it is being 
used to mine bitcoin.  Unfortunately, some Kubernetes systems are being 
attacked this way so you’ll want to watch your system closely.  The ONAP team 
is working to address this issue.

Thank you for your observations – this is how we make ONAP production grade.

Cheers,
Roger

From:  on behalf of 
"abdelmuhaimen.sea...@orange.com" 
Date: Saturday, March 24, 2018 at 5:54 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] ONAP on Kubernetes

Hi,

I deploy a minimum ONAP Amsterdam on Kubernetes, using a 64 GB RAM + 8 vCPU or 
16 vCPU.

The starting RAM utilization is around 30--40 GB RAM.

After one or two days, all the cpu cores reach 100%, and i reboot the VM, to be 
able to have some responsive feedback.

Sometimes, the HDD is full, and i have to reset the VM and redploy from scratch.

What is the reason for saturating all the CPU cores, or the RAM ?

Is there something I can do to minimize this behaviour ? should I use the 
Master Branch instead of Amsterdam ?

Thanks.

A. Seaudi

_



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] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2018-01-03 Thread Alexis de Talhouët
Hi Vidhu,

No, it’s not finished yet, still under testing. It got more complex than I 
expected, but it’s getting there :)
I’ll reply to this mail-thread once I believe it’s ready.

Regarding the branch, it will be Amsterdam branch, OOM has migrated its 
release-1.1.0 branch to Amsterdam, to comply to current branch naming scheme 
the project is following.

Thanks,
Alexis

> On Jan 3, 2018, at 12:10 PM, Vidhu Shekhar Pandey - ERS, HCL Tech 
>  wrote:
> 
> Hi Alexis,
>  
> Just wanted to know if the DCAEGEN2 is stable now? Should I pull OOM 1.1.0 or 
> the Amsterdam release to try it out?
>  
> Thanks,
> Vidhu
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, December 19, 2017 9:21 PM
> To: Vidhu Shekhar Pandey - ERS, HCL Tech  <mailto:vidhu.pan...@hcl.com>>
> Cc: Roger Maitland  <mailto:roger.maitl...@amdocs.com>>; onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support
>  
> Hi, it is still work in progress, but I’d say it’s almost done. Intensive 
> testing is currently being performed, so far with success. But I’d like to 
> have 3 complete runs with no hick-up to declare this ready.
>  
> Thanks,
> Alexis
> 
> 
> On Dec 18, 2017, at 2:19 PM, Vidhu Shekhar Pandey - ERS, HCL Tech 
> mailto:vidhu.pan...@hcl.com>> wrote:
>  
> Thanks Alexis and Roger for the information related to DCAEGEN2. Just wanted 
> to know when can I pull OOM 1.1.0 again to try it out?
>  
> Regards,
> Vidhu
>  
> From: Roger Maitland [mailto:roger.maitl...@amdocs.com 
> <mailto:roger.maitl...@amdocs.com>] 
> Sent: Thursday, December 14, 2017 10:00 PM
> To: Alexis de Talhouët  <mailto:adetalhoue...@gmail.com>>; Vidhu Shekhar Pandey - ERS, HCL Tech 
> mailto:vidhu.pan...@hcl.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: RE: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support
>  
> Vidhu, please keep in mind that OOM starts the DCAE controller which will 
> deploy VMs in the OpenStack domain.  As such you’ll need enough capacity in 
> your OpenStack cloud to deploy DCAE and any VNFs you are using.
>  
> Cheers,
> Roger
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Thursday, December 14, 2017 10:16 AM
> To: Vidhu Shekhar Pandey - ERS, HCL Tech  <mailto:vidhu.pan...@hcl.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support
>  
> Hi,
>  
> DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
> https://jira.onap.org/browse/OOM-508 
> <https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.onap.org%2Fbrowse%2FOOM-508&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=Z1jVUyAjDjLN3RaiogT5zgqMrxkkGkK7%2BktltP140NY%3D&reserved=0>
>  
> Implementation has been done, we’re currently testing the implementation to 
> make sure it’s working as expected.
>  
> You should be able to use it within the next week, with a fresh clone of OOM 
> branch release-1.1.0
> Make sure to have DNS Designate support in your OpenStack!
>  
> Close-loop won’t work without DCAE.
>  
> Thanks
>  
> 
> On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
> mailto:vidhu.pan...@hcl.com>> wrote:
>  
> Hi All,
> I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled 
> all the images using the prepull_docker.sh. But after creating the pods using 
> createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
> in 1.1.0 release? If not then when is it expected to be functional? Will I be 
> able to run the vFW demo close loop without DCAE? 
> More details below:
> The DCAE specific images shown are:
> root@hcl:~# docker images | grep dcae
> nexus3.onap.org 
> <https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-controller
>1.1-STAGING-latest ff839a80b8f112 weeks ago
> 694.6 MB
> nexus3.onap.org 
> <https://apac

Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2018-01-03 Thread Vidhu Shekhar Pandey - ERS, HCL Tech
Hi Alexis,

Just wanted to know if the DCAEGEN2 is stable now? Should I pull OOM 1.1.0 or 
the Amsterdam release to try it out?

Thanks,
Vidhu

From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com]
Sent: Tuesday, December 19, 2017 9:21 PM
To: Vidhu Shekhar Pandey - ERS, HCL Tech 
Cc: Roger Maitland ; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Hi, it is still work in progress, but I’d say it’s almost done. Intensive 
testing is currently being performed, so far with success. But I’d like to have 
3 complete runs with no hick-up to declare this ready.

Thanks,
Alexis


On Dec 18, 2017, at 2:19 PM, Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>> wrote:

Thanks Alexis and Roger for the information related to DCAEGEN2. Just wanted to 
know when can I pull OOM 1.1.0 again to try it out?

Regards,
Vidhu

From: Roger Maitland [mailto:roger.maitl...@amdocs.com]
Sent: Thursday, December 14, 2017 10:00 PM
To: Alexis de Talhouët 
mailto:adetalhoue...@gmail.com>>; Vidhu Shekhar Pandey 
- ERS, HCL Tech mailto:vidhu.pan...@hcl.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: RE: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Vidhu, please keep in mind that OOM starts the DCAE controller which will 
deploy VMs in the OpenStack domain.  As such you’ll need enough capacity in 
your OpenStack cloud to deploy DCAE and any VNFs you are using.

Cheers,
Roger

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
Sent: Thursday, December 14, 2017 10:16 AM
To: Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Hi,

DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
https://jira.onap.org/browse/OOM-508<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.onap.org%2Fbrowse%2FOOM-508&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=Z1jVUyAjDjLN3RaiogT5zgqMrxkkGkK7%2BktltP140NY%3D&reserved=0>

Implementation has been done, we’re currently testing the implementation to 
make sure it’s working as expected.

You should be able to use it within the next week, with a fresh clone of OOM 
branch release-1.1.0
Make sure to have DNS Designate support in your OpenStack!

Close-loop won’t work without DCAE.

Thanks

On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>> wrote:

Hi All,
I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled all 
the images using the prepull_docker.sh. But after creating the pods using 
createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
in 1.1.0 release? If not then when is it expected to be functional? Will I be 
able to run the vFW demo close loop without DCAE?
More details below:
The DCAE specific images shown are:
root@hcl:~# docker images | grep dcae
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-controller
   1.1-STAGING-latest ff839a80b8f112 weeks ago
694.6 MB
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-collector-common-event
   1.1-STAGING-latest e3daaf4b12 weeks ago537.3 MB
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-dmaapbc
  1.1-STAGING-latest 1fcf5b48d63b7 months ago   
 328.1 MB

The DCAE health check is failing

Starting Xvfb on display :88 with res 1280x1024x24
Executing robot tests at log level TRACE
==
OpenECOMP ETE
==
OpenECOMP

Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2017-12-19 Thread Alexis de Talhouët
Hi, it is still work in progress, but I’d say it’s almost done. Intensive 
testing is currently being performed, so far with success. But I’d like to have 
3 complete runs with no hick-up to declare this ready.

Thanks,
Alexis

> On Dec 18, 2017, at 2:19 PM, Vidhu Shekhar Pandey - ERS, HCL Tech 
>  wrote:
> 
> Thanks Alexis and Roger for the information related to DCAEGEN2. Just wanted 
> to know when can I pull OOM 1.1.0 again to try it out?
>  
> Regards,
> Vidhu
>  
> From: Roger Maitland [mailto:roger.maitl...@amdocs.com] 
> Sent: Thursday, December 14, 2017 10:00 PM
> To: Alexis de Talhouët ; Vidhu Shekhar Pandey - ERS, 
> HCL Tech 
> Cc: onap-discuss@lists.onap.org
> Subject: RE: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support
>  
> Vidhu, please keep in mind that OOM starts the DCAE controller which will 
> deploy VMs in the OpenStack domain.  As such you’ll need enough capacity in 
> your OpenStack cloud to deploy DCAE and any VNFs you are using.
>  
> Cheers,
> Roger
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Thursday, December 14, 2017 10:16 AM
> To: Vidhu Shekhar Pandey - ERS, HCL Tech  <mailto:vidhu.pan...@hcl.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support
>  
> Hi,
>  
> DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
> https://jira.onap.org/browse/OOM-508 
> <https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.onap.org%2Fbrowse%2FOOM-508&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=Z1jVUyAjDjLN3RaiogT5zgqMrxkkGkK7%2BktltP140NY%3D&reserved=0>
>  
> Implementation has been done, we’re currently testing the implementation to 
> make sure it’s working as expected.
>  
> You should be able to use it within the next week, with a fresh clone of OOM 
> branch release-1.1.0
> Make sure to have DNS Designate support in your OpenStack!
>  
> Close-loop won’t work without DCAE.
>  
> Thanks
>  
> 
> On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
> mailto:vidhu.pan...@hcl.com>> wrote:
>  
> Hi All,
> I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled 
> all the images using the prepull_docker.sh. But after creating the pods using 
> createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
> in 1.1.0 release? If not then when is it expected to be functional? Will I be 
> able to run the vFW demo close loop without DCAE? 
> More details below:
> The DCAE specific images shown are:
> root@hcl:~# docker images | grep dcae
> nexus3.onap.org 
> <https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-controller
>1.1-STAGING-latest ff839a80b8f112 weeks ago
> 694.6 MB
> nexus3.onap.org 
> <https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-collector-common-event
>1.1-STAGING-latest e3daaf4b12 weeks ago537.3 MB
> nexus3.onap.org 
> <https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-dmaapbc
>   1.1-STAGING-latest 1fcf5b48d63b7 months ago 
>328.1 MB
>  
> The DCAE health check is failing
>  
> Starting Xvfb on display :88 with res 1280x1024x24
> Executing robot tests at log level TRACE
> ==
> OpenECOMP ETE
> ==
> OpenECOMP ETE.Robot
> ==
> OpenECOMP ETE.Robot.Testsuites
> ==

Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2017-12-18 Thread Vidhu Shekhar Pandey - ERS, HCL Tech
Thanks Alexis and Roger for the information related to DCAEGEN2. Just wanted to 
know when can I pull OOM 1.1.0 again to try it out?

Regards,
Vidhu

From: Roger Maitland [mailto:roger.maitl...@amdocs.com]
Sent: Thursday, December 14, 2017 10:00 PM
To: Alexis de Talhouët ; Vidhu Shekhar Pandey - ERS, 
HCL Tech 
Cc: onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Vidhu, please keep in mind that OOM starts the DCAE controller which will 
deploy VMs in the OpenStack domain.  As such you’ll need enough capacity in 
your OpenStack cloud to deploy DCAE and any VNFs you are using.

Cheers,
Roger

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
Sent: Thursday, December 14, 2017 10:16 AM
To: Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Hi,

DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
https://jira.onap.org/browse/OOM-508<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.onap.org%2Fbrowse%2FOOM-508&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=Z1jVUyAjDjLN3RaiogT5zgqMrxkkGkK7%2BktltP140NY%3D&reserved=0>

Implementation has been done, we’re currently testing the implementation to 
make sure it’s working as expected.

You should be able to use it within the next week, with a fresh clone of OOM 
branch release-1.1.0
Make sure to have DNS Designate support in your OpenStack!

Close-loop won’t work without DCAE.

Thanks

On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>> wrote:

Hi All,
I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled all 
the images using the prepull_docker.sh. But after creating the pods using 
createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
in 1.1.0 release? If not then when is it expected to be functional? Will I be 
able to run the vFW demo close loop without DCAE?
More details below:
The DCAE specific images shown are:
root@hcl:~# docker images | grep dcae
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-controller
   1.1-STAGING-latest ff839a80b8f112 weeks ago
694.6 MB
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-collector-common-event
   1.1-STAGING-latest e3daaf4b12 weeks ago537.3 MB
nexus3.onap.org<https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnexus3.onap.org%2F&data=02%7C01%7Cvidhu.pandey%40hcl.com%7C3c00b10781cf4abe3c1708d5430fe663%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636488657975016933&sdata=cO4qvKf7lgMFFbrOULXROmxHFxkKbsh6vUaNfrhDgr8%3D&reserved=0>:10001/openecomp/dcae-dmaapbc
  1.1-STAGING-latest 1fcf5b48d63b7 months ago   
 328.1 MB

The DCAE health check is failing

Starting Xvfb on display :88 with res 1280x1024x24
Executing robot tests at log level TRACE
==
OpenECOMP ETE
==
OpenECOMP ETE.Robot
==
OpenECOMP ETE.Robot.Testsuites
==
OpenECOMP ETE.Robot.Testsuites.Health-Check :: Testing ecomp components are...
==
Basic DCAE Health Check   | FAIL |
ConnectionError: HTTPConnectionPool(host='dcae-controller.onap-dcae', 
port=8080): Max retries exceeded with url: /healthcheck (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known',))
--
Basic SDNGC Health Check  | PASS |
-

Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2017-12-14 Thread Roger Maitland
Vidhu, please keep in mind that OOM starts the DCAE controller which will 
deploy VMs in the OpenStack domain.  As such you’ll need enough capacity in 
your OpenStack cloud to deploy DCAE and any VNFs you are using.

Cheers,
Roger

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
Sent: Thursday, December 14, 2017 10:16 AM
To: Vidhu Shekhar Pandey - ERS, HCL Tech 
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

Hi,

DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
https://jira.onap.org/browse/OOM-508

Implementation has been done, we’re currently testing the implementation to 
make sure it’s working as expected.

You should be able to use it within the next week, with a fresh clone of OOM 
branch release-1.1.0
Make sure to have DNS Designate support in your OpenStack!

Close-loop won’t work without DCAE.

Thanks


On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
mailto:vidhu.pan...@hcl.com>> wrote:

Hi All,
I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled all 
the images using the prepull_docker.sh. But after creating the pods using 
createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
in 1.1.0 release? If not then when is it expected to be functional? Will I be 
able to run the vFW demo close loop without DCAE?
More details below:
The DCAE specific images shown are:
root@hcl:~# docker images | grep dcae
nexus3.onap.org<http://nexus3.onap.org/>:10001/openecomp/dcae-controller
   1.1-STAGING-latest ff839a80b8f112 weeks ago694.6 MB
nexus3.onap.org<http://nexus3.onap.org/>:10001/openecomp/dcae-collector-common-event
   1.1-STAGING-latest e3daaf4b12 weeks ago537.3 MB
nexus3.onap.org<http://nexus3.onap.org/>:10001/openecomp/dcae-dmaapbc   
   1.1-STAGING-latest 1fcf5b48d63b7 months ago328.1 MB

The DCAE health check is failing

Starting Xvfb on display :88 with res 1280x1024x24
Executing robot tests at log level TRACE
==
OpenECOMP ETE
==
OpenECOMP ETE.Robot
==
OpenECOMP ETE.Robot.Testsuites
==
OpenECOMP ETE.Robot.Testsuites.Health-Check :: Testing ecomp components are...
==
Basic DCAE Health Check   | FAIL |
ConnectionError: HTTPConnectionPool(host='dcae-controller.onap-dcae', 
port=8080): Max retries exceeded with url: /healthcheck (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known',))
--
Basic SDNGC Health Check  | PASS |
--
Basic A&AI Health Check   | PASS |

Thanks,
Vidhu
::DISCLAIMER:: 

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not guaranteed 
to be secure or error-free as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents (with or without referred errors) 
shall therefore not attach any liability on the originator or HCL or its 
affiliates. Views or opinions, if any, presented in this email are solely those 
of the author and may not necessarily reflect the views or opinions of HCL or 
its affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in error please delete it and 
notify the sender immediately. Before opening any email and/or attachments, 
please check them for viruses and other defects. 

 ::DISCLAIMER:: 

 The contents of this e-mail and any attachment(s) are confidential and 

Re: [onap-discuss] ONAP on Kubernetes OOM 1.1.0 - DCAE support

2017-12-14 Thread Alexis de Talhouët
Hi,

DCAEGEN2 support is currently being added to OOM. It’s tracked by JIRA 
https://jira.onap.org/browse/OOM-508 

Implementation has been done, we’re currently testing the implementation to 
make sure it’s working as expected.

You should be able to use it within the next week, with a fresh clone of OOM 
branch release-1.1.0
Make sure to have DNS Designate support in your OpenStack!

Close-loop won’t work without DCAE.

Thanks

> On Dec 14, 2017, at 7:30 AM, Vidhu Shekhar Pandey - ERS, HCL Tech 
>  wrote:
> 
> Hi All,
> I am using OOM 1.1.0 version to setup ONAP on Kubernetes. I have pre pulled 
> all the images using the prepull_docker.sh. But after creating the pods using 
> createAll.sh script all the pods are coming up except DCAE. Is DCAE supported 
> in 1.1.0 release? If not then when is it expected to be functional? Will I be 
> able to run the vFW demo close loop without DCAE? 
> More details below:
> The DCAE specific images shown are:
> root@hcl:~# docker images | grep dcae
> nexus3.onap.org :10001/openecomp/dcae-controller 
>   1.1-STAGING-latest ff839a80b8f112 weeks ago
> 694.6 MB
> nexus3.onap.org 
> :10001/openecomp/dcae-collector-common-event   
> 1.1-STAGING-latest e3daaf4b12 weeks ago537.3 MB
> nexus3.onap.org :10001/openecomp/dcae-dmaapbc
>   1.1-STAGING-latest 1fcf5b48d63b7 months ago
> 328.1 MB
>  
> The DCAE health check is failing
>  
> Starting Xvfb on display :88 with res 1280x1024x24
> Executing robot tests at log level TRACE
> ==
> OpenECOMP ETE
> ==
> OpenECOMP ETE.Robot
> ==
> OpenECOMP ETE.Robot.Testsuites
> ==
> OpenECOMP ETE.Robot.Testsuites.Health-Check :: Testing ecomp components are...
> ==
> Basic DCAE Health Check   | FAIL |
> ConnectionError: HTTPConnectionPool(host='dcae-controller.onap-dcae', 
> port=8080): Max retries exceeded with url: /healthcheck (Caused by 
> NewConnectionError(' 0x7f26aee31550>: Failed to establish a new connection: [Errno -2] Name or 
> service not known',))
> --
> Basic SDNGC Health Check  | PASS |
> --
> Basic A&AI Health Check   | PASS |
>  
> Thanks,
> Vidhu
> ::DISCLAIMER:: 
> 
>  The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects. 
> 
>  ::DISCLAIMER:: 
> 
>  The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, pres

Re: [onap-discuss] ONAP on Kubernetes with Rancher

2017-09-21 Thread Srinivasa Goda
Hi Roger,


Thanks for the reply. Also, I found one more difference in a yaml file, 
oom/kubernetes/multicloud/templates/framework-deployment.yaml. The line with '_ 
name: MSB_PORT' is throwing error while deploying containers with parsing 
error. I guess it should read '- name: MSB_PORT' instead.


Thanks,

Regards,

Srini


[Beta Tester Badge 3]



From: Roger Maitland 
Sent: Thursday, September 21, 2017 7:31 AM
To: Srinivasa Goda; onap-discuss@lists.onap.org
Subject: RE: ONAP on Kubernetes with Rancher

Hi Srini,

AAI introduced some configuration changes yesterday (Wednesday) which resulted 
in the crash loop you are seeing.  The problem has already been fixed locally 
and will be pushed to gerrit today. Thank you from pointing out the problem.

The OOM team (the Integration team is in the same situation) would appreciate a 
heads up from the project teams if there is a change in docker containers or 
configuration.  We’re happy to adapt to changes as they are made but there 
would be fewer interruptions if we knew of the changes in advance.

Thanks,
Roger
OOM Team

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Srinivasa Goda
Sent: Wednesday, September 20, 2017 11:58 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] ONAP on Kubernetes with Rancher


Hi,



I'm trying to bring up the ONAP on Kubernetes with rancher. Initially, I could 
bring it up but after sometime, i keep seeing some of the containers entering 
in 'CrashLoopBackOff' state and one container, -aai is in state 
init:0/1 for long time. I tried re-install everything from Ubuntu1604 VM to 
rancher and ONAP. I don't see any change. Any clues, pointers?



Thanks,

Regards,

Srini


[Beta Tester Badge 3]
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
Email Disclaimer | Amdocs
www.amdocs.com
Real-Time Data Management. Technology. Common Navigation. About about; Media 
Room media room


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


Re: [onap-discuss] ONAP on Kubernetes with Rancher

2017-09-21 Thread Roger Maitland
Hi Srini,

AAI introduced some configuration changes yesterday (Wednesday) which resulted 
in the crash loop you are seeing.  The problem has already been fixed locally 
and will be pushed to gerrit today. Thank you from pointing out the problem.

The OOM team (the Integration team is in the same situation) would appreciate a 
heads up from the project teams if there is a change in docker containers or 
configuration.  We're happy to adapt to changes as they are made but there 
would be fewer interruptions if we knew of the changes in advance.

Thanks,
Roger
OOM Team

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Srinivasa Goda
Sent: Wednesday, September 20, 2017 11:58 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] ONAP on Kubernetes with Rancher


Hi,



I'm trying to bring up the ONAP on Kubernetes with rancher. Initially, I could 
bring it up but after sometime, i keep seeing some of the containers entering 
in 'CrashLoopBackOff' state and one container, -aai is in state 
init:0/1 for long time. I tried re-install everything from Ubuntu1604 VM to 
rancher and ONAP. I don't see any change. Any clues, pointers?



Thanks,

Regards,

Srini


[Beta Tester Badge 3]
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