https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# opal
s
This message was deleted.
o
Hi @Jason McIntosh, 🤗 welcome. Note that the OPAL server checks out the entrie branch either way (that's how git works), and clients can then subscribe via topics (​POLICY_SUBSCRIPTION_DIRS) to only specific folders under the repo. 
OPAL_BUNDLE_IGNORE
filters out files/folder on the opal server (from the bundle it creates for the fetching client)
j
yeah 🙂 I was hoping it’d be nice to prefilter before clients picked it up
can be more performant to not load it all kinda thing.
hrmm, POLICY_SUBSCRIPTION_DIRS is a server side config?
o
I don't think this affects performance at all, but if you want you can use OPAL with a bundle API server instead of Git and create cached bundles there.
POLICY_SUBSCRIPTION_DIRS Is a client side env-var
j
ok so the opal client would use that to exclude policies. hrm.
o
(of course prefixed with "OPAL_") Yes and subscribe to updates to those policies
j
I was hoping to do a more centralized manage but guess it won’t matter TOO much
FYI https://github.com/jasonmcintosh/spinnaker-work/blob/main/applications/opa/opa-config.yml#L36 😉 OPA integration with Armory’s Spinnaker OPA plugin. Was testing using OPAL to distribute policies vs. kube mgmt. Like the opal architecture a touch more 😉
o
That's awesome 😊
j
shrug it’s an idea 🙂 Thought about my own websocket implementation with some internal custom servers to provide this - would have been API driven data lookups instead of git clone operations. Anyways. THIS CASE, sounds like we can ignore that manifest path - doesn’t do what I was kinda hoping it’d do and add a opal sidecar config to filter the path
POLICY_SUBSCRIPTION_DIRS - if i caught this right the equivalent would be to set this to
Copy code
POLICY_SUBSCRIPTION_DIRS: ["applications/opa/policies"]
kinda thing
I’ll dig through code confirm value parsing. Gets me closer to a flag to use
o
OPAL also has data updates , FYI, if you want to mix the two options
j
yeah it’s one of the things that caught my eye too
use case is PRIMARILY doing REGO policies to control deployments. e.g. https://github.com/jasonmcintosh/spinnaker-work/blob/main/applications/opa/policies/required_annotations.rego so your deployments have to have annotations or your deploys fail situation
o
j
nice think that’s what i was looking for.
💜 1
Copy code
OPAL client can subscribe to multiple policy topics, each policy topic is formatted as policy:{path} where path is a directory in the policy git repository (relative path to the root of the repository).
MINOR clarification. Not sure if a docs repo for a PR but:
Copy code
OPAL client can subscribe to multiple policy topics, each policy topic is formatted as {path1}:{path2} where path is a directory in the policy git repository (relative path to the root of the repository).
probably would be clearer 😉
hrm not sure that’s exactly accurate either
o
Yes this is confusing the “:” means two different things - once it’s just a delimiter in for the directory list ; And later it’s part of a prefix (literally “policy:“) for the event on the pub/sub channel
I think it’s better to simply drop this altogether (the information on the vent formatting is not useful here) I.e. it should be something like:
Copy code
OPAL client can subscribe to multiple policy topics, topics are based on paths where each path is a directory in the policy git repository (relative path to the root of the repository).
@Asaf Cohen WDYT ?
j
I like that “multiple policy topics” 🙂
NOW a question might be how to format it so it can do so
or could you name them or make it more intelligent. That’d complicate it pretty quick (and not sure the advantage).
shrug this case… each “directorY” separated by a “:” that defines a topic for changes to subscribe to
o
Currently the topics (for policies) are basically just the directories
j
yeah 🙂 I got that… was thinking bundle topics to notify on a mixed bag situation … way out in weeds here mentally 😉
o
😅 Well technically you can prefix them with something other than “policy:” and have some configuration on the server to omit them with the matching prefix
j
yeah this is my demo environment 🙂
✅ 1
o
I’m going into a meeting in 2 mins - please expect delayed replies 😅
j
lol no rush I’m getting OUT of meetings 😜
😇 1
JUST thought I’d share - so far so good on the config 😉 https://github.com/jasonmcintosh/spinnaker-work/blob/main/cluster/spinnaker/spinnaker.yaml#L73-L81 Opal sidecar on spinnaker is running fine - though I need to integrate some monitoring on it 😉 and my k8s deployment of opal is running well as well 😛 https://github.com/jasonmcintosh/spinnaker-work/blob/main/applications/opa/opa-config.yml
i need to dig through the helm chart more see what is possibly different
o
That’s awesome @Jason McIntosh! thank you for sharing I’m tagging @Raz Co - our helm chart specialist in case you’d need something in that area
💪 1
j
NP - one thing - looks like helm charts are missing startup probe config.
newer k8s probably should set that
r
It is a great idea to set a startup probe. I will add it to our list !
Open in Slack
PreviousNext
Powered by