Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Alexis, This is a great news. As you may have seen from another email, I didn’t succeed to run closed loop due to an issue with Policy (+ some other instabilities). Please let us know when you are able to repeat your test and the latest commits to OOM are in. Thanks, Marco From: <onap-discuss-boun...@lists.onap.org> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com> Date: Thursday, January 4, 2018 at 11:50 AM To: Helen Chen <helen.c...@huawei.com> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com>, onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi Helen, Thanks to the help I was given from folks this morning, I have completed the VFWCL testing, and everything is working fine. I’m going to re-do it from scratch, and then cover other use cases. But I’m confident all should be tested/validated by end of next week. I’m also re-freshing two wiki pages, one to deploy OOM on Kubernetes, on Rancher, in OpenStack: https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2Bon-2BKubernetes-2Bon-2BRancher-2Bin-2BOpenStack=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=aIkXsxkDb3hB0H-Pe9VoqFdcJ_yagzzk2c3lyya_PxQ=2tEbyh861_hTsE8DfseBTnsHj0zAuz-yAVm0Q651buw=> and one to run the vFW demo: https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_vFWCL-2Binstantiation-2C-2Btesting-2C-2Band-2Bdebuging=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=aIkXsxkDb3hB0H-Pe9VoqFdcJ_yagzzk2c3lyya_PxQ=z2dZk5QKKohdQyb2GHCa99p8R-oHOQ0H7u5wmrVELCE=> They both can look redundant with some other pages, but I trust they are very straightforward to follow (to David’s point and others). Thanks, Alexis On Jan 3, 2018, at 3:08 PM, Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>> wrote: Hi, Alexis, Sorry for the push. Could I get a timeframe for that? I would like the team to get hands on experience and based on that, making decision whether we’d like to keep both OOM and Heat for Beijing. My concern is how quick OOM could keep up with those new projects? (We are again need to make hard decision, keep both will need more resource for us). Regards, Helen Chen From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:42 AM To: "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>>, onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Brian, Yes, it does sound reasonable. That being said, I’m very much involved in finishing DCAE support in OOM. Once done, along with the testing the various use cases, I’ll sync up with Michael to provide a clear, straightforward documentation, both for setup and usage, providing tips and ways to debug. Thanks, Alexis On Jan 3, 2018, at 2:15 PM, FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>> wrote: Gary, I think Michael was trying to be complete in describing options with a plan to do a cleaned up documentation after it was working and scripted up. Perhaps its time to formally start a new page with the final recommended – single path and scripted install (I agree that it was daunting at the start to find the latest parts/procedure which was much simpler than the first procedure) Michael/Alexis – is that reasonable ? Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, January 03, 2018 1:16 PM To: PLATANIA, MARCO <plata...@research.att.com<mailto:plata...@research.att.com>>; Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-d
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Thanks for the update Alexis: very good progress! I will try it once it. Regards, Helen Chen From: Alexis de Talhouët <adetalhoue...@gmail.com> Date: Thursday, January 4, 2018 at 8:50 AM To: Helen Chen 00725961 <helen.c...@huawei.com> Cc: "FREEMAN, BRIAN D" <bf1...@att.com>, "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com>, onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi Helen, Thanks to the help I was given from folks this morning, I have completed the VFWCL testing, and everything is working fine. I’m going to re-do it from scratch, and then cover other use cases. But I’m confident all should be tested/validated by end of next week. I’m also re-freshing two wiki pages, one to deploy OOM on Kubernetes, on Rancher, in OpenStack: https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack and one to run the vFW demo: https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging<https://wiki.onap.org/display/DW/vFWCL+instantiation,+testing,+and+debuging> They both can look redundant with some other pages, but I trust they are very straightforward to follow (to David’s point and others). Thanks, Alexis On Jan 3, 2018, at 3:08 PM, Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>> wrote: Hi, Alexis, Sorry for the push. Could I get a timeframe for that? I would like the team to get hands on experience and based on that, making decision whether we’d like to keep both OOM and Heat for Beijing. My concern is how quick OOM could keep up with those new projects? (We are again need to make hard decision, keep both will need more resource for us). Regards, Helen Chen From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:42 AM To: "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>>, onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Brian, Yes, it does sound reasonable. That being said, I’m very much involved in finishing DCAE support in OOM. Once done, along with the testing the various use cases, I’ll sync up with Michael to provide a clear, straightforward documentation, both for setup and usage, providing tips and ways to debug. Thanks, Alexis On Jan 3, 2018, at 2:15 PM, FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>> wrote: Gary, I think Michael was trying to be complete in describing options with a plan to do a cleaned up documentation after it was working and scripted up. Perhaps its time to formally start a new page with the final recommended – single path and scripted install (I agree that it was daunting at the start to find the latest parts/procedure which was much simpler than the first procedure) Michael/Alexis – is that reasonable ? Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, January 03, 2018 1:16 PM To: PLATANIA, MARCO <plata...@research.att.com<mailto:plata...@research.att.com>>; Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-deploy in about 10 minutes (excluding DCAE). First impressions: * The system is highly dependent in using exact versions of everything: docker, kubernetes, helm, rancher, etc. If anything is slightly off, things would break, and it would not be obvious exactly what was wrong. As a result, it makes the system feel fragile. * The SDC intermittent issue above makes the OOM deployments feel not fully stable/repeatable yet. * The OOM “how-to” documentation has almost too much information, covering multiple options/paths that sometimes overlap (e.g. where to install Rancher server vs agent, whether to use the cd.sh or manually perform individual steps). This made it hard for a ne
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Hi Helen, Thanks to the help I was given from folks this morning, I have completed the VFWCL testing, and everything is working fine. I’m going to re-do it from scratch, and then cover other use cases. But I’m confident all should be tested/validated by end of next week. I’m also re-freshing two wiki pages, one to deploy OOM on Kubernetes, on Rancher, in OpenStack: https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack <https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack> and one to run the vFW demo: https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging <https://wiki.onap.org/display/DW/vFWCL+instantiation,+testing,+and+debuging> They both can look redundant with some other pages, but I trust they are very straightforward to follow (to David’s point and others). Thanks, Alexis > On Jan 3, 2018, at 3:08 PM, Yunxia Chen <helen.c...@huawei.com> wrote: > > Hi, Alexis, > Sorry for the push. Could I get a timeframe for that? I would like the team > to get hands on experience and based on that, making decision whether we’d > like to keep both OOM and Heat for Beijing. My concern is how quick OOM could > keep up with those new projects? (We are again need to make hard decision, > keep both will need more resource for us). > > Regards, > > Helen Chen > > From: <onap-discuss-boun...@lists.onap.org> on behalf of Alexis de Talhouët > <adetalhoue...@gmail.com> > Date: Wednesday, January 3, 2018 at 11:42 AM > To: "FREEMAN, BRIAN D" <bf1...@att.com> > Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com>, onap-discuss > <onap-discuss@lists.onap.org> > Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing > release > > Brian, > > Yes, it does sound reasonable. That being said, I’m very much involved in > finishing DCAE support in OOM. Once done, along with the testing the various > use cases, I’ll sync up with Michael to provide a clear, straightforward > documentation, both for setup and usage, providing tips and ways to debug. > > Thanks, > Alexis > > > On Jan 3, 2018, at 2:15 PM, FREEMAN, BRIAN D <bf1...@att.com > <mailto:bf1...@att.com>> wrote: > > Gary, > > I think Michael was trying to be complete in describing options with a plan > to do a cleaned up documentation after it was working and scripted up. > Perhaps its time to formally start a new page with the final recommended – > single path and scripted install (I agree that it was daunting at the start > to find the latest parts/procedure which was much simpler than the first > procedure) > > Michael/Alexis – is that reasonable ? > Brian > > > 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 Gary Wu > Sent: Wednesday, January 03, 2018 1:16 PM > To: PLATANIA, MARCO <plata...@research.att.com > <mailto:plata...@research.att.com>>; Alexis de Talhouët > <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E > <ma...@research.att.com <mailto:ma...@research.att.com>> > Cc: onap-discuss <onap-discuss@lists.onap.org > <mailto:onap-discuss@lists.onap.org>> > Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing > release > > My experience with OOM (excluding DCAE) so far is that SDC fails to pass > health check about half the time. When this happens, the best solution seems > to be re-deploying the entire ONAP again, and if you’re lucky it will work. > This appears to have been observed by others as well. The good thing is that > we can do the re-deploy in about 10 minutes (excluding DCAE). > > First impressions: > The system is highly dependent in using exact versions of everything: docker, > kubernetes, helm, rancher, etc. If anything is slightly off, things would > break, and it would not be obvious exactly what was wrong. As a result, it > makes the system feel fragile. > The SDC intermittent issue above makes the OOM deployments feel not fully > stable/repeatable yet. > The OOM “how-to” documentation has almost too much information, covering > multiple options/paths that sometimes overlap (e.g. where to install Rancher > server vs agent, whether to use the cd.sh or manually perform individual > steps). This made it hard for a newcomer to discern which steps need to be > run next given which other choices were made earlier, and it was also hard to > figure out if any mistakes were made performing some prior steps. > >
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Yes, Good plan, we can use the help of the documentation team and create an install page for the Beijing release. We will need to abstract out the varied undercloud environments as much as possible and provide a single RI (reference implementation) shared across dev/doc/test/arch/demo groups. Work is currently underway for a simple [helm up/down/upgrade] set of commands to run on this RI. /michael From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, January 3, 2018 14:15 To: Gary Wu <gary.i...@huawei.com>; PLATANIA, MARCO <plata...@research.att.com>; Alexis de Talhouët <adetalhoue...@gmail.com>; GILBERT, MAZIN E <ma...@research.att.com> Cc: onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Gary, I think Michael was trying to be complete in describing options with a plan to do a cleaned up documentation after it was working and scripted up. Perhaps its time to formally start a new page with the final recommended – single path and scripted install (I agree that it was daunting at the start to find the latest parts/procedure which was much simpler than the first procedure) Michael/Alexis – is that reasonable ? Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, January 03, 2018 1:16 PM To: PLATANIA, MARCO <plata...@research.att.com<mailto:plata...@research.att.com>>; Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-deploy in about 10 minutes (excluding DCAE). First impressions: * The system is highly dependent in using exact versions of everything: docker, kubernetes, helm, rancher, etc. If anything is slightly off, things would break, and it would not be obvious exactly what was wrong. As a result, it makes the system feel fragile. * The SDC intermittent issue above makes the OOM deployments feel not fully stable/repeatable yet. * The OOM “how-to” documentation has almost too much information, covering multiple options/paths that sometimes overlap (e.g. where to install Rancher server vs agent, whether to use the cd.sh or manually perform individual steps). This made it hard for a newcomer to discern which steps need to be run next given which other choices were made earlier, and it was also hard to figure out if any mistakes were made performing some prior steps. I was not able to find any information on how to deploy DCAE via OOM; the most I got so far was that the DCAE controller container was able to bring up about half of the expected DCAE VMs, but not enough to be able to pass the DCAE health check. Thanks, Gary From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO (MARCO) Sent: Wednesday, January 03, 2018 9:15 AM To: Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release I’ve been playing around with the OOM solution for a while and I was able to instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I installed a minimal version of DCAE (only the collector and one CDAP container with the Threshold-crossing microservices) to run closed loop, waiting for the whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps due to out-of-sync configuration in my environment. I’m trying to fix this and see how far I can go with closed loop. Marco From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:36 AM To: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lis
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Alexis, Just to dovetail Vijay's email. When a DMaaP message router subscriber issues a long polling call on a topic, if the topic does not exist, the rest call is returned with an error response code. A DMaaP message router topic is created on the message router o.owhen: 1. if the topic is anonymous (no authentication) the first publication of a message to the topic causes topic being created in message router; 2 if the topic is a secured topic, it is created by an explicit provisioning operation. For R1, all topics are anonymous. So seeing the error response code when polling a topic does not necessarily mean an error condition, --could be that the publisher has not had anything to publish yet as Vijay explained. The proper behavior for a subscriber getting a topic not exist error would be to poll again after a timeout. If non existent anonymous topic does create a problem on subscriber, one mitigation at integration level could be to publish an empty message to this topic using curl command in message router initialization to cause the topic in question being created. Regards, Lusheng Sent via the Samsung Galaxy S7, an AT 4G LTE smartphone Original message From: "VENKATESH KUMAR, VIJAY" <vv7...@att.com> Date: 1/3/18 4:22 PM (GMT-05:00) To: Alexis de Talhouët <adetalhoue...@gmail.com>, Helen Chen <helen.c...@huawei.com> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com>, onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Alexis, If the DMAAP instance was newly instantiated, then the following topic - unauthenticated.DCAE_CL_OUTPUT will be created when first Closed loop event gets published (either by TCA or Holmes services under DCAE). For vFW, TCA publishes the closedloop event. There are few things to check if * TCA health check passes in consul (alternative you can check CDAP gui http://:11011/oldcdap/ns/cdap_tca_hi_lo/apps//programs/flows/TCAVESCollectorFlow/runs<https://urldefense.proofpoint.com/v2/url?u=http-3A__-253ccdap02-2520host-2520ip-253e-3A11011_oldcdap_ns_cdap-5Ftca-5Fhi-5Flo_apps_-253cinstancename-2520generated-253e_programs_flows_TCAVESCollectorFlow_runs=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=qiKb3LQBLje9oy8MjG3MEx1ia4mIocif7RoUY8WQWV8=LH-MKZdIWVHaja3XBczXZ4AE6als5vx22ZshEfRPmYg=bJge5Mo7WxIIjedn5mffZeUcV5gCXxqsGCAsx6YkUsg=>) * Incoming events exceed the threshold defined for vFw (https://wiki.onap.org/display/DW/Policy+R1+Amsterdam+Functional+Test+Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Policy-2BR1-2BAmsterdam-2BFunctional-2BTest-2BCases=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=qiKb3LQBLje9oy8MjG3MEx1ia4mIocif7RoUY8WQWV8=LH-MKZdIWVHaja3XBczXZ4AE6als5vx22ZshEfRPmYg=p9CdfrfwcS_TQAd1xou1meVsYhEGaLQOjOm_ETKQZkg=>) Regards, Vijay From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët Sent: Wednesday, January 03, 2018 3:31 PM To: Helen Chen <helen.c...@huawei.com> Cc: GILBERT, MAZIN E <ma...@research.att.com>; onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, I’m currently facing an issue in DCAE, so I have to reverse engineer the whole thing (along with Policy)… I have everything working already, it’s just that i have one topic, (or few topics, dunno yet) not being created. Mainly, the one used by DCAE to publish close loop events: unauthenticated.DCAE_CL_OUTPUT (re: [onap-discuss] [OOM]Close-loop testing - No such topic exists.-[unauthenticated.DCAE_CL_OUTPUT] —> https://lists.onap.org/pipermail/onap-discuss/2017-December/007011.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_pipermail_onap-2Ddiscuss_2017-2DDecember_007011.html=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6WYcUG7NY-ZxfqWx5MmzVQ=6srfnt5sS26zu4Rb6KKEw4D_hoIu57H6qAIwGnJSsAg=t4w94vXetT9gLnwDRN0gcRolZX8ce38BiuUvWajcMpg=>) If someone can help me figure this out, I will be one step ahead and very close to completion. OOM is (for me) working reliably on the Amsterdam branch. DCAE setup is being created/working correctly with c/26647; I have health check passing fine; policy seems to be working as expected, I was able to successfully correlated the VNF heat stack with an operational policy. I can mount correctly the VNF. Now i’m very much at the last step of my testing; having DCAE receive/publish events for CL (vFWCL use case). Once done, my gut feeling is other use cases Brian mentioned will work as expected. I’m willing to help you guys set it up and assist if things are failing. Anyhow, I hope to get this done within the next week or so, but if some DCAE expert wish to c
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Alexis, If the DMAAP instance was newly instantiated, then the following topic - unauthenticated.DCAE_CL_OUTPUT will be created when first Closed loop event gets published (either by TCA or Holmes services under DCAE). For vFW, TCA publishes the closedloop event. There are few things to check if * TCA health check passes in consul (alternative you can check CDAP gui http://:11011/oldcdap/ns/cdap_tca_hi_lo/apps//programs/flows/TCAVESCollectorFlow/runs<http://%3ccdap02%20host%20ip%3e:11011/oldcdap/ns/cdap_tca_hi_lo/apps/%3cinstancename%20generated%3e/programs/flows/TCAVESCollectorFlow/runs>) * Incoming events exceed the threshold defined for vFw (https://wiki.onap.org/display/DW/Policy+R1+Amsterdam+Functional+Test+Cases) Regards, Vijay From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët Sent: Wednesday, January 03, 2018 3:31 PM To: Helen Chen <helen.c...@huawei.com> Cc: GILBERT, MAZIN E <ma...@research.att.com>; onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, I’m currently facing an issue in DCAE, so I have to reverse engineer the whole thing (along with Policy)… I have everything working already, it’s just that i have one topic, (or few topics, dunno yet) not being created. Mainly, the one used by DCAE to publish close loop events: unauthenticated.DCAE_CL_OUTPUT (re: [onap-discuss] [OOM]Close-loop testing - No such topic exists.-[unauthenticated.DCAE_CL_OUTPUT] —> https://lists.onap.org/pipermail/onap-discuss/2017-December/007011.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_pipermail_onap-2Ddiscuss_2017-2DDecember_007011.html=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6WYcUG7NY-ZxfqWx5MmzVQ=6srfnt5sS26zu4Rb6KKEw4D_hoIu57H6qAIwGnJSsAg=t4w94vXetT9gLnwDRN0gcRolZX8ce38BiuUvWajcMpg=>) If someone can help me figure this out, I will be one step ahead and very close to completion. OOM is (for me) working reliably on the Amsterdam branch. DCAE setup is being created/working correctly with c/26647; I have health check passing fine; policy seems to be working as expected, I was able to successfully correlated the VNF heat stack with an operational policy. I can mount correctly the VNF. Now i’m very much at the last step of my testing; having DCAE receive/publish events for CL (vFWCL use case). Once done, my gut feeling is other use cases Brian mentioned will work as expected. I’m willing to help you guys set it up and assist if things are failing. Anyhow, I hope to get this done within the next week or so, but if some DCAE expert wish to chime and help me figure out my current issue that would help me _a lot_. Regarding Gary first comment, Docker, Kubernetes, Helm and Rancher versions have to match, indeed, as they are very working in harmony. Best is to check Rancher website for that (http://rancher.com/docs/rancher/v1.6/en/hosts/#supported-docker-versions<https://urldefense.proofpoint.com/v2/url?u=http-3A__rancher.com_docs_rancher_v1.6_en_hosts_-23supported-2Ddocker-2Dversions=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=6WYcUG7NY-ZxfqWx5MmzVQ=6srfnt5sS26zu4Rb6KKEw4D_hoIu57H6qAIwGnJSsAg=zPTC7xytrR6rBKWrajKyneEde2NowbV3jotb4x6H6PM=>). Kubernetes is very picky on which Docker version to use, Rancher usually supports one Docker version that is also supported by Kubernetes. Regarding SDC instability, I think work is currently being done to fix it, having tracked this though. Regards, Alexis On Jan 3, 2018, at 3:08 PM, Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>> wrote: Hi, Alexis, Sorry for the push. Could I get a timeframe for that? I would like the team to get hands on experience and based on that, making decision whether we’d like to keep both OOM and Heat for Beijing. My concern is how quick OOM could keep up with those new projects? (We are again need to make hard decision, keep both will need more resource for us). Regards, Helen Chen From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:42 AM To: "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>>, onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Brian, Yes, it does sound reasonable. That being said, I’m very much involved in finishing DCAE support in OOM. Once done, along with the testing the various use cases, I’ll sync up with Michael to provide a clear, straightforward documentation, both for setup and usage, providing tips and w
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Hi, Alexis, Sorry for the push. Could I get a timeframe for that? I would like the team to get hands on experience and based on that, making decision whether we’d like to keep both OOM and Heat for Beijing. My concern is how quick OOM could keep up with those new projects? (We are again need to make hard decision, keep both will need more resource for us). Regards, Helen Chen From: <onap-discuss-boun...@lists.onap.org> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com> Date: Wednesday, January 3, 2018 at 11:42 AM To: "FREEMAN, BRIAN D" <bf1...@att.com> Cc: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com>, onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Brian, Yes, it does sound reasonable. That being said, I’m very much involved in finishing DCAE support in OOM. Once done, along with the testing the various use cases, I’ll sync up with Michael to provide a clear, straightforward documentation, both for setup and usage, providing tips and ways to debug. Thanks, Alexis On Jan 3, 2018, at 2:15 PM, FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>> wrote: Gary, I think Michael was trying to be complete in describing options with a plan to do a cleaned up documentation after it was working and scripted up. Perhaps its time to formally start a new page with the final recommended – single path and scripted install (I agree that it was daunting at the start to find the latest parts/procedure which was much simpler than the first procedure) Michael/Alexis – is that reasonable ? Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, January 03, 2018 1:16 PM To: PLATANIA, MARCO <plata...@research.att.com<mailto:plata...@research.att.com>>; Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-deploy in about 10 minutes (excluding DCAE). First impressions: * The system is highly dependent in using exact versions of everything: docker, kubernetes, helm, rancher, etc. If anything is slightly off, things would break, and it would not be obvious exactly what was wrong. As a result, it makes the system feel fragile. * The SDC intermittent issue above makes the OOM deployments feel not fully stable/repeatable yet. * The OOM “how-to” documentation has almost too much information, covering multiple options/paths that sometimes overlap (e.g. where to install Rancher server vs agent, whether to use the cd.sh or manually perform individual steps). This made it hard for a newcomer to discern which steps need to be run next given which other choices were made earlier, and it was also hard to figure out if any mistakes were made performing some prior steps. I was not able to find any information on how to deploy DCAE via OOM; the most I got so far was that the DCAE controller container was able to bring up about half of the expected DCAE VMs, but not enough to be able to pass the DCAE health check. Thanks, Gary From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO (MARCO) Sent: Wednesday, January 03, 2018 9:15 AM To: Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release I’ve been playing around with the OOM solution for a while and I was able to instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I installed a minimal version of DCAE (only the collector and one CDAP container with the Threshold-crossing microservices) to run closed loop, waiting for the whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps due to out-of-sync configuration in my environment. I’m trying to fix this and see how far I can go with closed loop. Marco From: <onap-discuss-boun...@lists.onap.org<mailto:onap
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Brian, Yes, it does sound reasonable. That being said, I’m very much involved in finishing DCAE support in OOM. Once done, along with the testing the various use cases, I’ll sync up with Michael to provide a clear, straightforward documentation, both for setup and usage, providing tips and ways to debug. Thanks, Alexis > On Jan 3, 2018, at 2:15 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > > Gary, > > I think Michael was trying to be complete in describing options with a plan > to do a cleaned up documentation after it was working and scripted up. > Perhaps its time to formally start a new page with the final recommended – > single path and scripted install (I agree that it was daunting at the start > to find the latest parts/procedure which was much simpler than the first > procedure) > > Michael/Alexis – is that reasonable ? > Brian > > > 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 Gary Wu > Sent: Wednesday, January 03, 2018 1:16 PM > To: PLATANIA, MARCO <plata...@research.att.com > <mailto:plata...@research.att.com>>; Alexis de Talhouët > <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E > <ma...@research.att.com <mailto:ma...@research.att.com>> > Cc: onap-discuss <onap-discuss@lists.onap.org > <mailto:onap-discuss@lists.onap.org>> > Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing > release > > My experience with OOM (excluding DCAE) so far is that SDC fails to pass > health check about half the time. When this happens, the best solution seems > to be re-deploying the entire ONAP again, and if you’re lucky it will work. > This appears to have been observed by others as well. The good thing is that > we can do the re-deploy in about 10 minutes (excluding DCAE). > > First impressions: > The system is highly dependent in using exact versions of everything: docker, > kubernetes, helm, rancher, etc. If anything is slightly off, things would > break, and it would not be obvious exactly what was wrong. As a result, it > makes the system feel fragile. > The SDC intermittent issue above makes the OOM deployments feel not fully > stable/repeatable yet. > The OOM “how-to” documentation has almost too much information, covering > multiple options/paths that sometimes overlap (e.g. where to install Rancher > server vs agent, whether to use the cd.sh or manually perform individual > steps). This made it hard for a newcomer to discern which steps need to be > run next given which other choices were made earlier, and it was also hard to > figure out if any mistakes were made performing some prior steps. > > I was not able to find any information on how to deploy DCAE via OOM; the > most I got so far was that the DCAE controller container was able to bring up > about half of the expected DCAE VMs, but not enough to be able to pass the > DCAE health check. > > Thanks, > Gary > > > 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 PLATANIA, MARCO > (MARCO) > Sent: Wednesday, January 03, 2018 9:15 AM > To: Alexis de Talhouët <adetalhoue...@gmail.com > <mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E (MAZIN E) > <ma...@research.att.com <mailto:ma...@research.att.com>> > Cc: onap-discuss <onap-discuss@lists.onap.org > <mailto:onap-discuss@lists.onap.org>> > Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing > release > > I’ve been playing around with the OOM solution for a while and I was able to > instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. > I installed a minimal version of DCAE (only the collector and one CDAP > container with the Threshold-crossing microservices) to run closed loop, > waiting for the whole DCAE platform to be ready. I wasn’t able to run closed > loop yet, perhaps due to out-of-sync configuration in my environment. I’m > trying to fix this and see how far I can go with closed loop. > > Marco > > From: <onap-discuss-boun...@lists.onap.org > <mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët > <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>> > Date: Wednesday, January 3, 2018 at 11:36 AM > To: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com > <mailto:ma...@resear
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Gary, I think Michael was trying to be complete in describing options with a plan to do a cleaned up documentation after it was working and scripted up. Perhaps its time to formally start a new page with the final recommended – single path and scripted install (I agree that it was daunting at the start to find the latest parts/procedure which was much simpler than the first procedure) Michael/Alexis – is that reasonable ? Brian From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, January 03, 2018 1:16 PM To: PLATANIA, MARCO <plata...@research.att.com>; Alexis de Talhouët <adetalhoue...@gmail.com>; GILBERT, MAZIN E <ma...@research.att.com> Cc: onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-deploy in about 10 minutes (excluding DCAE). First impressions: * The system is highly dependent in using exact versions of everything: docker, kubernetes, helm, rancher, etc. If anything is slightly off, things would break, and it would not be obvious exactly what was wrong. As a result, it makes the system feel fragile. * The SDC intermittent issue above makes the OOM deployments feel not fully stable/repeatable yet. * The OOM “how-to” documentation has almost too much information, covering multiple options/paths that sometimes overlap (e.g. where to install Rancher server vs agent, whether to use the cd.sh or manually perform individual steps). This made it hard for a newcomer to discern which steps need to be run next given which other choices were made earlier, and it was also hard to figure out if any mistakes were made performing some prior steps. I was not able to find any information on how to deploy DCAE via OOM; the most I got so far was that the DCAE controller container was able to bring up about half of the expected DCAE VMs, but not enough to be able to pass the DCAE health check. Thanks, Gary From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO (MARCO) Sent: Wednesday, January 03, 2018 9:15 AM To: Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release I’ve been playing around with the OOM solution for a while and I was able to instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I installed a minimal version of DCAE (only the collector and one CDAP container with the Threshold-crossing microservices) to run closed loop, waiting for the whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps due to out-of-sync configuration in my environment. I’m trying to fix this and see how far I can go with closed loop. Marco From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:36 AM To: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Mazin, So far, that I’m aware of, a few ppl from various company have tried OOM Amsterdam, and have successfully deployed vFWCL. If you want names and email, I guess I can find them for you. We’re currently testing vFWCL close loop with DCAE being deployed by OOM; I’d say it’s 80% done. Thanks, Alexis On Jan 3, 2018, at 11:21 AM, GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> wrote: Thanks Roger. Have there been other groups who have managed to bring up Amsterdam with OOM (with and without DCAE)? Can you point me to any so I can understand their experience. mazin On Jan 3, 2018, at 11:15 AM, Roger Maitland <roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>> wrote: Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://urldefense.proofpoint.com/v
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
ption:'',filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,field:healthcheck,index:AWAtYVuQYNh0ncCb5IdF,key:healthcheck,negate:!f,type:phrase,value:FAIL),script:(script:(inline:'boolean%20compare(Supplier%20s,%20def%20v)%20%7Breturn%20s.get()%20%3D%3D%20v;%7Dcompare(()%20-%3E%20%7B%20def%20msg%20%3D%20doc%5B!'message.keyword!'%5D.value;%0Aif%20(doc%5B!'message.keyword!'%5D.value%20!!%3D%20null)%20%7B%0Aif%20(doc%5B!'message.keyword!'%5D.value%20%3D~%20%2FHealth%20Check%2F)%20%7B%0A%20%20if%20(doc%5B!'message.keyword!'%5D.value%20%3D~%20%2FPASS%2F)%20%7B%20%0A%20%20%20%20return%20%22PASS%22;%0A%20%20%7D%0A%20%20else%20%7B%0A%20%20%20%20return%20%22FAIL%22;%0A%20%20%7D%0A%7D%0A%7D%0Areturn%20null;%20%7D,%20params.value);',lang:painless,params:(value:FAIL),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:3,type:visualization),(col:9,id:AWAtuTVI3NTXK5mX2kuP,panelIndex:2,row:1,size_x:4,size_y:3,type:visualization),(col:1,id:AWAtuBTY3NTXK5mX2kuO,panelIndex:3,row:7,size_x:6,size_y:3,type:visualization),(col:1,id:AWAttmqB3NTXK5mX2kuN,panelIndex:4,row:4,size_x:6,size_y:3,type:visualization),(col:7,id:AWAtvHtY3NTXK5mX2kuR,panelIndex:6,row:4,size_x:6,size_y:6,type:visualization)),query:(match_all:()),timeRestore:!f,title:'CD%20Health%20Check',uiState:(),viewMode:view)
From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu
Sent: Wednesday, January 3, 2018 13:16
To: PLATANIA, MARCO (MARCO) <plata...@research.att.com>; Alexis de Talhouët
<adetalhoue...@gmail.com>; GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com>
Cc: onap-discuss <onap-discuss@lists.onap.org>
Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
My experience with OOM (excluding DCAE) so far is that SDC fails to pass health
check about half the time. When this happens, the best solution seems to be
re-deploying the entire ONAP again, and if you’re lucky it will work. This
appears to have been observed by others as well. The good thing is that we can
do the re-deploy in about 10 minutes (excluding DCAE).
First impressions:
· The system is highly dependent in using exact versions of everything:
docker, kubernetes, helm, rancher, etc. If anything is slightly off, things
would break, and it would not be obvious exactly what was wrong. As a result,
it makes the system feel fragile.
· The SDC intermittent issue above makes the OOM deployments feel not
fully stable/repeatable yet.
· The OOM “how-to” documentation has almost too much information,
covering multiple options/paths that sometimes overlap (e.g. where to install
Rancher server vs agent, whether to use the cd.sh or manually perform
individual steps). This made it hard for a newcomer to discern which steps
need to be run next given which other choices were made earlier, and it was
also hard to figure out if any mistakes were made performing some prior steps.
I was not able to find any information on how to deploy DCAE via OOM; the most
I got so far was that the DCAE controller container was able to bring up about
half of the expected DCAE VMs, but not enough to be able to pass the DCAE
health check.
Thanks,
Gary
From:
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO
(MARCO)
Sent: Wednesday, January 03, 2018 9:15 AM
To: Alexis de Talhouët
<adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>; GILBERT, MAZIN E
(MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>>
Cc: onap-discuss
<onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>
Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
I’ve been playing around with the OOM solution for a while and I was able to
instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I
installed a minimal version of DCAE (only the collector and one CDAP container
with the Threshold-crossing microservices) to run closed loop, waiting for the
whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps
due to out-of-sync configuration in my environment. I’m trying to fix this and
see how far I can go with closed loop.
Marco
From:
<onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>>
on behalf of Alexis de Talhouët
<adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>>
Date: Wednesday, January 3, 2018 at 11:36 AM
To: "GILBERT, MAZIN E (MAZIN E)"
<ma...@research.att.com<mailto:ma...@research.att.com>>
Cc: onap-discuss
<onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>
Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Mazin,
So far, that I’m aware of, a few ppl from v
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
My experience with OOM (excluding DCAE) so far is that SDC fails to pass health check about half the time. When this happens, the best solution seems to be re-deploying the entire ONAP again, and if you’re lucky it will work. This appears to have been observed by others as well. The good thing is that we can do the re-deploy in about 10 minutes (excluding DCAE). First impressions: · The system is highly dependent in using exact versions of everything: docker, kubernetes, helm, rancher, etc. If anything is slightly off, things would break, and it would not be obvious exactly what was wrong. As a result, it makes the system feel fragile. · The SDC intermittent issue above makes the OOM deployments feel not fully stable/repeatable yet. · The OOM “how-to” documentation has almost too much information, covering multiple options/paths that sometimes overlap (e.g. where to install Rancher server vs agent, whether to use the cd.sh or manually perform individual steps). This made it hard for a newcomer to discern which steps need to be run next given which other choices were made earlier, and it was also hard to figure out if any mistakes were made performing some prior steps. I was not able to find any information on how to deploy DCAE via OOM; the most I got so far was that the DCAE controller container was able to bring up about half of the expected DCAE VMs, but not enough to be able to pass the DCAE health check. Thanks, Gary From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO (MARCO) Sent: Wednesday, January 03, 2018 9:15 AM To: Alexis de Talhouët <adetalhoue...@gmail.com>; GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com> Cc: onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release I’ve been playing around with the OOM solution for a while and I was able to instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I installed a minimal version of DCAE (only the collector and one CDAP container with the Threshold-crossing microservices) to run closed loop, waiting for the whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps due to out-of-sync configuration in my environment. I’m trying to fix this and see how far I can go with closed loop. Marco From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> Date: Wednesday, January 3, 2018 at 11:36 AM To: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com<mailto:ma...@research.att.com>> Cc: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Mazin, So far, that I’m aware of, a few ppl from various company have tried OOM Amsterdam, and have successfully deployed vFWCL. If you want names and email, I guess I can find them for you. We’re currently testing vFWCL close loop with DCAE being deployed by OOM; I’d say it’s 80% done. Thanks, Alexis On Jan 3, 2018, at 11:21 AM, GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> wrote: Thanks Roger. Have there been other groups who have managed to bring up Amsterdam with OOM (with and without DCAE)? Can you point me to any so I can understand their experience. mazin On Jan 3, 2018, at 11:15 AM, Roger Maitland <roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>> wrote: Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Doom.git-3Ba-3Dshortlog-3Bh-3Drefs_heads_amsterdam=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=uYM-V22L0V1EhonUacGlX4_i-MF4XdWNLtYWzReGYA4=> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which t
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
I’ve been playing around with the OOM solution for a while and I was able to instantiate the vFW, vLB/vDNS, plus another dummy generic VNF that I created. I installed a minimal version of DCAE (only the collector and one CDAP container with the Threshold-crossing microservices) to run closed loop, waiting for the whole DCAE platform to be ready. I wasn’t able to run closed loop yet, perhaps due to out-of-sync configuration in my environment. I’m trying to fix this and see how far I can go with closed loop. Marco From: <onap-discuss-boun...@lists.onap.org> on behalf of Alexis de Talhouët <adetalhoue...@gmail.com> Date: Wednesday, January 3, 2018 at 11:36 AM To: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com> Cc: onap-discuss <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Mazin, So far, that I’m aware of, a few ppl from various company have tried OOM Amsterdam, and have successfully deployed vFWCL. If you want names and email, I guess I can find them for you. We’re currently testing vFWCL close loop with DCAE being deployed by OOM; I’d say it’s 80% done. Thanks, Alexis On Jan 3, 2018, at 11:21 AM, GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com<mailto:ma...@research.att.com>> wrote: Thanks Roger. Have there been other groups who have managed to bring up Amsterdam with OOM (with and without DCAE)? Can you point me to any so I can understand their experience. mazin On Jan 3, 2018, at 11:15 AM, Roger Maitland <roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>> wrote: Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Doom.git-3Ba-3Dshortlog-3Bh-3Drefs_heads_amsterdam=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=uYM-V22L0V1EhonUacGlX4_i-MF4XdWNLtYWzReGYA4=> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. 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 Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>; Sauvageau, David <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=EJl3g98o-LmIGfk4sjynukqHSJ3epLjqaYO4anfC954=> ___ onap-discuss mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=j7WSvxdz-fKgmH76NuG-x2cW3E_oZL4nU8OuXiW1ylM= ___ onap-discuss mailing list onap-discuss@lists.onap.org<mailto:onap-discus
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
I think Kang has a script to do the vCPE use case all in one shot (the 7 minute demo :) Brian From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] Sent: Wednesday, January 03, 2018 11:34 AM To: FREEMAN, BRIAN D <bf1...@att.com> Cc: Roger Maitland <roger.maitl...@amdocs.com>; Helen Chen <helen.c...@huawei.com>; onap-discuss <onap-discuss@lists.onap.org>; David Sauvageau <david.sauvag...@bell.ca> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Brian, For now, vFW instantiate, vFWCL instantiate has been tested and validated. vFWVL close loop (APPC LCM modifyconfig) is currently being tested. Once done, I can cover the other use cases you provided to ensure it’s working as expected. Help will be appreciated at this point. Thanks Alexis On Jan 3, 2018, at 11:30 AM, FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>> wrote: Roger, I have used OOM as well and it has made substantial progress and I think it should be used for Beijing. One thing I haven’t had a chance to check. Are all the opensource VNF uses cases successfully running off an OOM installation ? 1. vFW instantiate 2. vDNS instantiate 3. VDNS closed loop scaling with and without MultiVIM (dnsscaling vnf instantiate) 4. vFWCL instantiate 5. vFWCL closed loop (APPC LCM modifyconfig) 6. vCPE Infrastucture instantiate 7. vCPE customer vG instantiate (uses macro api into SO and generic resource API into SDNC) 8. vCPE closed loop with and without MultiVIM (restart vGMUX) 9. vIMS (Clearwater) – we havent run this in a while but if the previous instantiates work the vIMS should as well. Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland Sent: Wednesday, January 03, 2018 11:15 AM To: Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>; onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>; Sauvageau, David <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Doom.git-3Ba-3Dshortlog-3Bh-3Drefs_heads_amsterdam=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=a8o3_j9rZ_qxfABkALfHIrYohgel2N4EJVYEzCKmwJI=EhDAoxdNx8-Zbks0BGCLaqwTASRIWIhhqqxQxi3PcFE=> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:3,type:visualization),(col:9,id:AWAtuTVI3NTXK5mX2kuP,panelIndex:2,row:1,size_x:4,size_y:3,type:visualization),(col:1,id:AWAtuBTY3NTXK5mX2kuO,panelIndex:3,row:7,size_x:6,size_y:3,type:visualization),(col:1,id:AWAttmqB3NTXK5mX2kuN,panelIndex:4,row:4,size_x:6,size_y:3,type:visualization),(col:7,id:AWAtvHtY3NTXK5mX2kuR,panelIndex:6,row:4,size_x:6,size_y:6,type:visualization)),query:(match_all:()),timeRestore:!f,title:%27CD%20Health%20Check%27,uiState:(),viewMode:view)> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. 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 Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>; Sauvageau, David <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam p
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Brian, For now, vFW instantiate, vFWCL instantiate has been tested and validated. vFWVL close loop (APPC LCM modifyconfig) is currently being tested. Once done, I can cover the other use cases you provided to ensure it’s working as expected. Help will be appreciated at this point. Thanks Alexis > On Jan 3, 2018, at 11:30 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > > Roger, > > I have used OOM as well and it has made substantial progress and I think it > should be used for Beijing. > One thing I haven’t had a chance to check. > > Are all the opensource VNF uses cases successfully running off an OOM > installation ? > > vFW instantiate > vDNS instantiate > VDNS closed loop scaling with and without MultiVIM (dnsscaling vnf > instantiate) > vFWCL instantiate > vFWCL closed loop (APPC LCM modifyconfig) > vCPE Infrastucture instantiate > vCPE customer vG instantiate (uses macro api into SO and generic resource API > into SDNC) > vCPE closed loop with and without MultiVIM (restart vGMUX) > vIMS (Clearwater) – we havent run this in a while but if the previous > instantiates work the vIMS should as well. > > Brian > > > From: onap-discuss-boun...@lists.onap.org > [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Roger Maitland > Sent: Wednesday, January 03, 2018 11:15 AM > To: Yunxia Chen <helen.c...@huawei.com>; onap-discuss > <onap-discuss@lists.onap.org>; Sauvageau, David <david.sauvag...@bell.ca> > Subject: Re: [onap-discuss] [integration][oom] OOM readiness for Beijing > release > > Hi Helen, > > David is on vacation so I’ll answer - OOM is ready. > > The OOM team has been working with the Integration team and the entire ONAP > community to create the amsterdam > <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Doom.git-3Ba-3Dshortlog-3Bh-3Drefs_heads_amsterdam=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=a8o3_j9rZ_qxfABkALfHIrYohgel2N4EJVYEzCKmwJI=EhDAoxdNx8-Zbks0BGCLaqwTASRIWIhhqqxQxi3PcFE=> > release of OOM which is now available. There is a continuous delivery > system that deploys the master branch of all of the ONAP components with OOM > – here > <http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:3,type:visualization),(col:9,id:AWAtuTVI3NTXK5mX2kuP,panelIndex:2,row:1,size_x:4,size_y:3,type:visualization),(col:1,id:AWAtuBTY3NTXK5mX2kuO,panelIndex:3,row:7,size_x:6,size_y:3,type:visualization),(col:1,id:AWAttmqB3NTXK5mX2kuN,panelIndex:4,row:4,size_x:6,size_y:3,type:visualization),(col:7,id:AWAtvHtY3NTXK5mX2kuR,panelIndex:6,row:4,size_x:6,size_y:6,type:visualization)),query:(match_all:()),timeRestore:!f,title:%27CD%20Health%20Check%27,uiState:(),viewMode:view)> > is the dashboard. As this system is effectively continuously evaluating > ONAP health this should be very useful for the Integration team to quickly > identify component submissions that result in a degradation. > > The initial version of DCAE support is under final testing. This version > brings up the DCAE controller which then brings up the rest of the DCAE VMs. > There is a discussion scheduled for tomorrow between the OOM and DCAE team on > a more fully containerized solution. The OOM team is also working on > deploying OpenStack DNS Designate to simply the deployment of OpenStack > infrastructure required for DCAE. We’ll let the community know when this is > ready. > > 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 Yunxia Chen > Sent: Tuesday, January 2, 2018 5:25 PM > To: onap-discuss <onap-discuss@lists.onap.org > <mailto:onap-discuss@lists.onap.org>>; Sauvageau, David > <david.sauvag...@bell.ca <mailto:david.sauvag...@bell.ca>> > Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release > > Hi, David, > > Happy new year and it was very nice to talk with you at Santa Clara. Is OOM > ready for Integration team to take over to test the Beijing release, maybe > start with Amsterdam project first? From last meeting, it seems have a little > bit issue on DCAE, has it resolved yet? > > Regards, > Helen Chen > 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
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
We’ll talk to Lusheng about Designate tomorrow. We’re just trying to help out the community but if it is going away soon maybe we can avoid this work. Cheers, Roger From: Yunxia Chen [mailto:helen.c...@huawei.com] Sent: Wednesday, January 3, 2018 11:22 AM To: Roger Maitland <roger.maitl...@amdocs.com>; onap-discuss <onap-discuss@lists.onap.org>; Sauvageau, David <david.sauvag...@bell.ca> Subject: Re: [integration][oom] OOM readiness for Beijing release Thank you Roger. I will give it a try. Regarding designate, I thought DCAE team will leverage multi-vim to handle it at future release instead of using designate for R2+ release. Regards, Helen Chen From: Roger Maitland <roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>> Date: Wednesday, January 3, 2018 at 8:15 AM To: Helen Chen 00725961 <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>, onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>, "Sauvageau, David" <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: RE: [integration][oom] OOM readiness for Beijing release Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://gerrit.onap.org/r/gitweb?p=oom.git;a=shortlog;h=refs/heads/amsterdam> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. 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 Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>; Sauvageau, David <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen 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/email-disclaimer> ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Thanks Roger. Have there been other groups who have managed to bring up Amsterdam with OOM (with and without DCAE)? Can you point me to any so I can understand their experience. mazin On Jan 3, 2018, at 11:15 AM, Roger Maitland <roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>> wrote: Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Doom.git-3Ba-3Dshortlog-3Bh-3Drefs_heads_amsterdam=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=uYM-V22L0V1EhonUacGlX4_i-MF4XdWNLtYWzReGYA4=> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:3,type:visualization),(col:9,id:AWAtuTVI3NTXK5mX2kuP,panelIndex:2,row:1,size_x:4,size_y:3,type:visualization),(col:1,id:AWAtuBTY3NTXK5mX2kuO,panelIndex:3,row:7,size_x:6,size_y:3,type:visualization),(col:1,id:AWAttmqB3NTXK5mX2kuN,panelIndex:4,row:4,size_x:6,size_y:3,type:visualization),(col:7,id:AWAtvHtY3NTXK5mX2kuR,panelIndex:6,row:4,size_x:6,size_y:6,type:visualization)),query:(match_all:()),timeRestore:!f,title:%27CD%20Health%20Check%27,uiState:(),viewMode:view)> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. 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 Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>; Sauvageau, David <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=EJl3g98o-LmIGfk4sjynukqHSJ3epLjqaYO4anfC954=> ___ onap-discuss mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=_dlaJi5cUYGfdQpkrTvOLmwKf9nHldPQl5dmZYtz2iQ=j7WSvxdz-fKgmH76NuG-x2cW3E_oZL4nU8OuXiW1ylM= ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] [integration][oom] OOM readiness for Beijing release
Thank you Roger. I will give it a try. Regarding designate, I thought DCAE team will leverage multi-vim to handle it at future release instead of using designate for R2+ release. Regards, Helen Chen From: Roger Maitland <roger.maitl...@amdocs.com> Date: Wednesday, January 3, 2018 at 8:15 AM To: Helen Chen 00725961 <helen.c...@huawei.com>, onap-discuss <onap-discuss@lists.onap.org>, "Sauvageau, David" <david.sauvag...@bell.ca> Subject: RE: [integration][oom] OOM readiness for Beijing release Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://gerrit.onap.org/r/gitweb?p=oom.git;a=shortlog;h=refs/heads/amsterdam> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. Cheers, Roger From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org>; Sauvageau, David <david.sauvag...@bell.ca> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen 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] [integration][oom] OOM readiness for Beijing release
Hi Helen, David is on vacation so I’ll answer - OOM is ready. The OOM team has been working with the Integration team and the entire ONAP community to create the amsterdam<https://gerrit.onap.org/r/gitweb?p=oom.git;a=shortlog;h=refs/heads/amsterdam> release of OOM which is now available. There is a continuous delivery system that deploys the master branch of all of the ONAP components with OOM – here<http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(description:%27%27,filters:!(),options:(darkTheme:!f),panels:!((col:1,id:AWAts77k3NTXK5mX2kuM,panelIndex:1,row:1,size_x:8,size_y:3,type:visualization),(col:9,id:AWAtuTVI3NTXK5mX2kuP,panelIndex:2,row:1,size_x:4,size_y:3,type:visualization),(col:1,id:AWAtuBTY3NTXK5mX2kuO,panelIndex:3,row:7,size_x:6,size_y:3,type:visualization),(col:1,id:AWAttmqB3NTXK5mX2kuN,panelIndex:4,row:4,size_x:6,size_y:3,type:visualization),(col:7,id:AWAtvHtY3NTXK5mX2kuR,panelIndex:6,row:4,size_x:6,size_y:6,type:visualization)),query:(match_all:()),timeRestore:!f,title:%27CD%20Health%20Check%27,uiState:(),viewMode:view)> is the dashboard. As this system is effectively continuously evaluating ONAP health this should be very useful for the Integration team to quickly identify component submissions that result in a degradation. The initial version of DCAE support is under final testing. This version brings up the DCAE controller which then brings up the rest of the DCAE VMs. There is a discussion scheduled for tomorrow between the OOM and DCAE team on a more fully containerized solution. The OOM team is also working on deploying OpenStack DNS Designate to simply the deployment of OpenStack infrastructure required for DCAE. We’ll let the community know when this is ready. Cheers, Roger From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yunxia Chen Sent: Tuesday, January 2, 2018 5:25 PM To: onap-discuss <onap-discuss@lists.onap.org>; Sauvageau, David <david.sauvag...@bell.ca> Subject: [onap-discuss] [integration][oom] OOM readiness for Beijing release Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer> ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [integration][oom] OOM readiness for Beijing release
Hi, David, Happy new year and it was very nice to talk with you at Santa Clara. Is OOM ready for Integration team to take over to test the Beijing release, maybe start with Amsterdam project first? From last meeting, it seems have a little bit issue on DCAE, has it resolved yet? Regards, Helen Chen ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
