In our experience, this is likely due to the deployment of this particular component, dep-config-binding-service-7b9cfb76b8-l75mp, timed out. And this is usually due to docker image pulling taking too long. We are working on a work around for this in the DCAE bootstrap container, ETA EoB today.
In the meanwhile, if you could prepull images before starting helm install, you could try to run the helm install with an additional parameter to override the default (which is alway pull), something like this: helm install local/onap -n dev --namespace onap --set global.pullPolicy=IfNotPresent to avoid pulling images... There is a job, called dcae-bootstrap, that deploys these 8 pods. You can check its logs for details. Because it is a job, the pod is gone once it is done. You may have to use -a to see it. Lusheng On May 4, 2018, at 3:40 PM, Michal Ptacek <m.pta...@partner.samsung.com<mailto:m.pta...@partner.samsung.com>> wrote: Thanks Lusheng for your hints, I see some trace of dcae now, but it's in "Error syncing pod" state dcae dep-config-binding-service-7b9cfb76b8-l75mp 0/2 ContainerCreating 0 6h need to troubleshoot this further .... Michal --------- Original Message --------- Sender : JI, LUSHENG (LUSHENG) <l...@research.att.com<mailto:l...@research.att.com>> Date : 2018-05-04 19:36 (GMT+1) Title : Re: [onap-discuss] DCAE deployment in R2 (oom or heat) To : Michal Ptacek<m.pta...@partner.samsung.com<mailto:m.pta...@partner.samsung.com>> CC : null<onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Michal, When the DCAE is fully deployed by OOM, there should be 8 additional pods deployed. They may be under a different namespace “dcae”, depends on configuration. You may check it out in place, for example the Integration-Jenkins tenant of Intel/Windriver lab. Moreover, additional components can be deployed at operation time by CLAMP. Lusheng On May 4, 2018, at 10:03 AM, Michal Ptacek <m.pta...@partner.samsung.com<mailto:m.pta...@partner.samsung.com>> wrote: Hi, will it be possible to fully deploy DCAE using OOM in R2 ? It seems that trend is to move to containers from VM's, also DCAE is going into this direction. what I heard here https://wiki.onap.org/display/DW/Meetings?preview=/13598723/31982711/dcae-weekly-20180503.mp4<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Meetings-3Fpreview-3D_13598723_31982711_dcae-2Dweekly-2D20180503.mp4&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=qiKb3LQBLje9oy8MjG3MEx1ia4mIocif7RoUY8WQWV8&m=SfX1Jew16Goa7zdY46mVmCqWmV94u9SoqB-0vskjXi0&s=y0Gl75ExbNOYPTPIKf7rBJBKGpNgzj6NbSIc1CvQPMo&e=> is that currently DCAE can be spawned on single bootstrap VM (8G-16G of RAM) and all components are running as docker containers, also it should be possible to deploy it fully using OOM. I tried today to deploy latest ONAP in OOM (multinode, single node is not possible anymore with 110 pods per k8s host limitation) but I see just following dcae pods .... onap beijing-dcae-cloudify-manager-fb9f5d6bd-bss2n 1/1 Running 0 4h onap beijing-dcae-db-0 1/1 Running 0 4h onap beijing-dcae-db-1 1/1 Running 0 2h onap beijing-dcae-healthcheck-78999885d5-5hts8 1/1 Running 0 4h onap beijing-dcae-redis-0 1/1 Running 0 4h onap beijing-dcae-redis-1 1/1 Running 0 3h onap beijing-dcae-redis-2 1/1 Running 0 2h onap beijing-dcae-redis-3 1/1 Running 0 2h onap beijing-dcae-redis-4 1/1 Running 0 2h onap beijing-dcae-redis-5 1/1 Running 0 1h where is the rest ? please advise have a nice weekend thanks, Michal _______________________________________________ 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&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qiKb3LQBLje9oy8MjG3MEx1ia4mIocif7RoUY8WQWV8&m=SfX1Jew16Goa7zdY46mVmCqWmV94u9SoqB-0vskjXi0&s=5U2AVfg95KozM5YSXorQ-G-l2rTeDt3psYlLwZ-9eok&e= <Mail Attachment.gif>
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
