Yes the OOM team have modelled the intra and inter ONAP component dependencies but clearly there is more work to do here to get it perfect. ONAP need to come up perfectly every time as this is a critical aspect of automated healing. As there are major internal architecture changes coming from many of the project teams in the next couple weeks we’ll work with all of the teams to improve the dependency management as we introduce these changes into ONAP.
Most of the ‘readiness probes’ that are used to indicate the ability to start the next component in the dependency chain are based on simply checking if a port is available. This can be problematic as often initialization must be done after the port is up (common with the DBs) is isn’t reliably being checked (a fixed sleep time is common). The readiness probes could be changed to check for the completion of initialization so there are tools we can use to get to deterministic startup but the entire community needs to work together on this goal. Cheers, Roger From: <onap-discuss-boun...@lists.onap.org> on behalf of "FREEMAN, BRIAN D" <bf1...@att.com> Date: Wednesday, March 14, 2018 at 12:07 PM To: Gary Wu <gary.i...@huawei.com>, "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [INT] Robot INIT and Robot InstantiateVFW after Healthcheck ? Gary, My apologies – I will re-calibrate to use “ETE” :) I think OOM is working the dependency issue but not sure of the status/delivery time frame. I suspect we dont need all healthchecks to run for init to work. We might need a new test template to call “Model Distribution From ASDC” which appears to have the right checks on distribution now but not sure. Brian From: Gary Wu [mailto:gary.i...@huawei.com] Sent: Wednesday, March 14, 2018 12:03 PM To: FREEMAN, BRIAN D <bf1...@att.com>; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] [INT] Robot INIT and Robot InstantiateVFW after Healthcheck ? Hi Brian, Yes, we will be adding demo init or instanceVFW tests to the daily deployment test jobs shortly once the Beijing code is stabilized for M4. Currently we can’t even get successful health checks yet. Is the OOM team working on fixing the deployment issues so that the pod restarts can be avoided? Also to clarify on terminology, the term “CSIT” is used for API tests of a single or a few docker containers (i.e. not against a full ONAP instnace). Tests against a full ONAP instance is more what we refer to as an “ETE” (end-to-end) scenario. We want to add more and more ETE test suites to be run automatically via Jenkins as new test suites get implemented. 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 FREEMAN, BRIAN D Sent: Wednesday, March 14, 2018 8:40 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] [INT] Robot INIT and Robot InstantiateVFW after Healthcheck ? Gary, In working with OOM over the last few week it seem like the best way to detect problems is to run the demo-k8s.sh init and then to check via op0001 if SO, AAI and SDNC picked up the models. Usually on a fresh OOM they do not. The repair is to delete the AAI model-loader POD, the SO POD and the UEB-Listener POD in SDNC (I usually do dmaap-listener as well). K8 will restart those PODs. I then do a redistribute in SDC as op001 and see success. Every once in a while I also have to delete the sdc-be/sdc-fe to repeat the deletes if the sdc-be wasnt up properly (usually because I didnt check healtcheck first on sdc) I’m wondier if this is a CSIT jenkins job we should do to run init and instantiate VFW after healthcheck ? Or just a custom check after ‘demo-k8s.sh init’ or ‘demo-k8s.sh onap init’ to test that the distribution actually succeeded to demonstrate installation health ? The distribute data can be retrieve by the catalog services API /sdc2/rest/v1/catalog/services/1eb7b5c8-9ec9-4090-8bef-322d82f5400c/distribution) where the 1eb... is the catalog-service-uuid to get the distribution ID and then /sdc2/rest/v1/catalog/services/distribution/6cf76bba-62d7-4dcb-8410-6760fc54cee7 to get the table of the actual status for the notified components Brian 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
