Increasing Retry Attempts or Disabling Restart Behavior for OPA Bundle API Access #386
-
At present, OPA restarts after four unsuccessful attempts to access the bundle API. Is there a way to increase this number or disable this behavior entirely? We have OPA deployed as a sidecar, which receives data through the push method from a container running in the same pod. However, we would like to transition to a bundle API approach. If we modify the OPA injection configuration to enable the bundle API and the local container has not yet implemented the Bundle API, OPA will restart. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Hi @daniel-pebble 👋 Not sure I follow here... what do you mean by "OPA restarts"? AFAIK, OPA never shuts down other than when told so by a signal sent from the outside (SIGTERM, SIGKILL, etc). Applications can't really restart themselves, as once they shut down they're... well, shut down 🙂 I'm guessing you have some outside process polling OPA for readyness? And eventually decides that it has waited long enough. If you could share some more details, that would be helpful. |
Beta Was this translation helpful? Give feedback.
-
Hi @anderseknert , thanks for the prompt response. I did check the pod events and as far as I can tell k8s isn't restarting the container. Readiness probe failed: Get "http://10.244.0.67:8282/health?plugins": dial tcp 10.244.0.67:8282: connect: connection refused {"addrs":["localhost:8181"],"diagnostic-addrs":["0.0.0.0:8282"],"level":"info","msg":"Initializing server.","time":"2023-03-31T19:23:34Z"} {"decision_id":"6005562e-59b3-40fe-ae75-dbaaea8c4b72","input":{"attributes":{"destination":{"address":{"socketAddress":{"address":"10.244.0.67","portValue":8282}}},"metadataContext":{},"request":{"http":{"headers":{":authority":"10.244.0.67:8282",":method":"GET",":path":"/health?plugins",":scheme":"http","accept":"/","user-agent":"kube-probe/1.26","x-forwarded-proto":"http","x-request-id":"751a12cc-ead2-4352-9e56-e34d7f90d25c"},"host":"10.244.0.67:8282","id":"14310980792228578821","method":"GET","path":"/health?plugins","protocol":"HTTP/1.1","scheme":"http"},"time":"2023-03-31T19:23:54.438553Z"},"source":{"address":{"socketAddress":{"address":"10.244.0.1","portValue":60354}}}},"parsed_body":null,"parsed_path":["health"],"parsed_query":{"plugins":[""]},"truncated_body":false,"version":{"encoding":"protojson","ext_authz":"v3"}},"labels":{"id":"605dd96e-0716-4693-9849-761679068a2c","version":"0.49.0-envoy"},"level":"info","metrics":{"timer_rego_external_resolve_ns":700,"timer_rego_query_eval_ns":1035492,"timer_server_handler_ns":1303891},"msg":"Decision Log","path":"pebble/oceans/auth/allow","result":true,"time":"2023-03-31T19:23:54Z","timestamp":"2023-03-31T19:23:54.440630954Z","type":"openpolicyagent.org/decision_logs"} Pod config OPA config config.yaml: | |
Beta Was this translation helpful? Give feedback.
Hi @daniel-pebble 👋 Not sure I follow here... what do you mean by "OPA restarts"? AFAIK, OPA never shuts down other than when told so by a signal sent from the outside (SIGTERM, SIGKILL, etc). Applications can't really restart themselves, as once they shut down they're... well, shut down 🙂 I'm guessing you have some outside process polling OPA for readyness? And eventually decides that it has waited long enough. If you could share some more details, that would be helpful.