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