Hi Morgan, It seems on our cloud the liveness probe fails and pod gets killed/restarted. Maybe this is causing some loss of config on the db as the error says the backed hostAddress cannot connect. Ca

#clamp #oom

our last daily master 5/10 Clamp OK (https://logs.onap.org/onap-integration/daily/onap_daily_pod4_master/10-05-2020_08-10/infrastructure-healthcheck/k8s/kubernetes-status/index.html) 4/10 Clamp OK (ht

#clamp #oom

Hi, Clamp is failing to deploy in recent master deployments of OOM. The backend is getting refused when trying to connect to it's mariadb pod due to permissions. Has anyone seen this issue on OOM mast

#clamp #oom

Hello all, When you start MariaDB of clamp, have you set the masterPassword in helm command? If not, could you please try to restart clamp adding the masterPassword setting at the end of the helm comm

#clamp

++ BRIAN Hi Brian, we are facing this issue from last week posted multiple time to community but didn't got any response. Can you please loop a right person or team who can helps us a bit in resolving

#clamp

Hi Team, The mariadb error in clamp still not resolved. Now mariadb issue is causing Policy, VFC components and by which healthchecks(14-vfc, 1-policy, 1-clamp) also failing. From the attached mariadb

#clamp

The bootstrap log shows that we did not have the “500 error” that has happened sometimes in the gating environment. Instead, the log shows that the bootstrap process successfully requested the Kuberne

#clamp #dcaegen2

Hi Team, As a part of ONAP-Frankfurt bringup, we have cloned latest oom today. But 1 healthcheck is failing i.e. Clamp, because frankfurt-clamp-backend-5b54fb589f-zk4ns pod is in CrashLoopBackOff stat

#frankfurt #clamp

Hi Vijay, The log file shared was after the redeployment. Regards, Naveen

#clamp #dcaegen2

Hi Naveen, That’s good. Btw, logs you shared was it before or after the redeployment (couldn’t say from the timestamp)? Based on the log file provided, TCA deployment was successful and healthcheck sh

#clamp #dcaegen2

Hi Vijay, Thanks for the response. Now dcae-tca-analysis pod came up, after executing the commands you provided and DCAE healthcheck is passing now. PFA of tca_pod_describe_podlogs.txt . Regards, Nave

#clamp #dcaegen2

Sylvain - The cfy 500 error is noticed only on gating (something specific to that environment causing random failure). This issue here appears different – deployment through bootstrap/cloudify made th

#clamp #dcaegen2

Hi JACK, The issue is dep-dcae-tca-analytics pod is failed to appear after dcae successful deployment. PFA of results and dcae_bootstrap_logs.txt. Please provide your inputs for the same. Regards, Nav

#clamp #dcaegen2

Well let's wait for Jack thoughts because when the pod fails to appear, it's usually a 500 error on our side :/ I hope he'll be able to find something! De : Naveen S. Sankad [naveen.sankad@...] E

#clamp #dcaegen2

Hi sylvain, From dcae bootstrap pod logs there is no "Error 500" in dcae-tca-analysis deployment. dcae-tca-analysis deployment is success in log. Please refer the attached dcae_bootstrap_logs.txt . Bu

#clamp #dcaegen2

Hi Lukasz, The policy api component has a limitation in this release where requires you to start fresh with a database if you perform an upgrade, which seems may be the case in your situation as I'm g

#clamp #policy

Thanks Sebastien, Unfortunately it didn't work. I tried different combinations of parameters. Interestingly I had this working on bit older Frankfurt lab from a month ago. And now exact same policy is

#clamp #policy

Lukasz, Here is an example of what we had for scaleout (try to put v0.0.1 for policyVersion) Otherwise you can look at the logs in policy-api container but I don’t think you will get more details than

#clamp #policy

Thanks Sebastien for help. Here's the policy: { "tca_policy": { "domain": "measurementsForVfScaling", "metricsPerEventName": [ { "policyScope": "testPolicyScope", "thresholds": [ { "version": "1", "se

#clamp #policy

Lukasz, Policy rejects the TCA monitoring policy (onap.policies.monitoring.cdap.tca.hi.lo.app, APP box in clamp). It means there is an issue with the configuration of it, Could you copy paste the JSON

#clamp #policy