This message was deleted.
# opal
s
This message was deleted.
o
Hi @Charlotte Brady you are, right this seems to have slipped between the cracks. I'll make sure it gets prioritized
❤️ 1
@Tuan-Nhi Le - I see this is actually part of a PR you worked on (https://github.com/permitio/opal/pull/282); Any chance you can take another stab at this? 🙂 [No pressure]
@Charlotte Brady can you share logs of the described scenario? ; I’ve been giving this a poke myself, and while running in debug at least - this seems to work fine - the values get parsed correctly. So I’m probably missing something.
c
@Or Weis This is an intermittent issue, when the opal-server takes too long to clone the policy repo, the opal-client doesn’t wait enough to fetch this, resulting in an error. Here are the opal-client logs. You can see it attempts 5 times only even though we have
OPAL_POLICY_STORE_CONN_RETRY={"wait_strategy":"exponential","wait_time":50,"attempts":10}
as a test (within opal-client docker-compose environment)
@Or Weis here are the opal-server logs too
o
Oooh , got ya. So there’s some terminology confusion here. The policy store- (which connection with is configured by
OPAL_POLICY_STORE_CONN_RETRY
is OPA, the local agent OPAL-client loads policy into. (It’s called POLICY_STORE because soon OPAL will support additional agents no just OPA 🤫) The connection to the policy-source or bundle server is a different one, not controlled by this parameter. I defiently can see how the name here can be misleading. Let me check about config to control access to the policy source / server
HI @Charlotte Brady, so I’m sorry to say there’s no controlling configuration for that; but I’ll start a PR to add it
Here’s the PR: https://github.com/permitio/opal/pull/359 adding
POLICY_UPDATER_CONN_RETRY
as well as exposing a new wait strategy (randomized exponential backoff) , and a max wait time option
🙌 1
c
thanks so much! seems like that will do the trick 🙂
😇 1
o
FYI this was just merged into the master branch