Hello Bhavesh, In guilin, policy and I believe sdc uses the cert-initializer, so they are generated on the fly at container instantiation. I am not sure about aai. If you are in elalto, you may be abl

#aai #policy #policy　dev-policy-xacml-pdp #portal #oom

Sai, This error is more than likely being related to the expired dmaap certificates. Unfortunately, I don't have a good procedure to replace them. Being in Dublin, I think you're going to be running i

That's good Sai, if you got to this point, the certificate problems between clamp and policy are solved, and now you are hitting something else. There's a known issue in Dublin where PAP loses synchro

Hello Sai, I think that there must be something in the generated certificates and keystore/truststore that isn't quite right for these 2 components to talk. I think it may be worth to try out a plain

Hello Vivek, Another possibility if you have access to a guilin lab is to get the generated keystore from the pap pod, and use it to replace the keystore in the "dublin" pap pod. In guilin, similar to

Hi Ken, The scenario that you described looks very similar to the vFirewall usecase. May be you know already, but take a look at the scripts that Brian F. put together for automating the scenario in t

#controlloop

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