I've seen these, Jack. Check out this ticket for additional info: https://jira.onap.org/browse/OOM-2534 Jorge

Hi Andrew, I see the same problem as I am incorporating the certInitializer into policy. The system installs fine but the individual components are unregistered (still see dmaap, portal, etc .. resour

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

These are the latest Frankfurt images for policy, Yuriy: onap/policy-api:2.2.4 onap/policy-pap:2.2.3 onap/policy-pe:1.6.4 onap/policy-pdpd-cl:1.6.4 onap/policy-apex-pdp:2.3.2 onap/policy-xacml-pdp:2.2

Hello Krzysztof, Some teams are migrating from legacy components (that will eventually will be deprecated) to non-legacy ones. Configuration is defined here ( see Values.restserver.user + .Values.rest

I added a patch on top of your review, Kryzysztof, if you can take a look. It's passing healthchecks now in my side. I'll keep an eye on for the oom deploy job results, hopefully it will pass the heal

Hi Krysztof, Is this the patch that you are testing? https://gerrit.onap.org/r/c/oom/+/104915 If it is, I can install, give it a try and work with local folks as needed. Let me know. Jorge

Hello Sivakumar, The trigger_policy should point to an entry in the policies array: vIMSPolicy1 controlLoop: abatement: false controlLoopName: LOOP_Closed_Loop_vIMS_v3_0_VIMS_SPROUT0_analytics_ms time

Hello Siva, It seems a malformed policy. I take it that this is El Alto or Dublin. From policy standpoint you could dump policies by doing a "kubectl exec -it " into drools container and dumping the p

Hello, you'll need one of these 2 solutions: a) make newton client trust the aaf ca root certificate from which policy derives their certificates (same as other components), this would be configuratio

#policy #elalto

Hello Deepak, Based on your log message, it looks like you may be hitting the issue reported in the POLICY-1939 ticket in El Alto. The workaround would be to bounce the pod that the message is complai

Hello Aniello, The Policy GUI is part of the legacy architecture which will eventually be deprecated and it is not coupled with the CLAMP GUI (new architecture). You can look at policies through CLAMP

#policy

Hi Min, Yes, in the message, the "name":"default", should be "name":"amsterdam" to match the drools controller name. If you look in the actual "createPolicy" messages using the legacy APIs, https://gi

#policy #drools

Check out in the drools container the $POLICY_LOGS/network.log , look for configuration messages over the PDPD-CONFIGURATION channel, you should see an update configuration request commanding drools t

#policy #drools

Hello, Please monitor this ticket for resolution to this problem: https://jira.onap.org/browse/CLAMP-484. It's related to the payload field being a (empty) string. Best regards, Jorge

#drools #controlloop #dublin #clamp

Hello, Try changing "ueb" to dmaap, for example: http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/dmaap/DCAE_TOPIC/events @./dc

#drools #policy #dmaap

Hello Charlton, Some additional feedback besides Sandeep. I installed Casablanca release, and don't see the errors you've shown in the drools logs when deploying policies, not sure if in your case it

#policy #controlloop

Hi Vidya, There’s POLICY-1810 that covers the error you pointed out in El Alto. Having said that, I believe that for your purposes, the error is mostly cosmetic, as you see the operational policy bein

Right with the new architecture, the work will be done with the “usecases” controller .. there are 2 architectures, a) legacy (amsterdam), b) “new” (usecases) that are supported. May be a bit confusin

Hello Michal, The usecases controller is cooked in the image, it should be there with no further action. Please check with these 2 commands in the container: $ telemetry get controllers Jorge