This message was deleted.

I’m almost sure that no, only the dict itself.

Which value?

I mean that you should escape the value you are passing in the

OPAL_DATA_CONFIG_SOURCES

env.

I think I’m following. I’ll probably have the Helm chart format this value somehow.

yeah sure, let me know if you need help with that, escaping with helm can be frustrating sometimes 😉

I’m more worried about the functionality of my data fetcher than anything else.

You got this 😉 💪

I’m trying to write my data fetcher to be as generic as possible. As I understand the config will come into the OPA system and basically define what to fetch. But what I’m figuring out now is how that comes into play with

_process_

. Because I’m not sure if I can find some clever way to allow an end user to supply their own ‘transform’ logic. Maybe by including a

func

as an input to config?

Mmm - that does sound super generic. Who’s the end user in this scenario? A dev on your team?

Well, if I can write the perfectly generic data fetcher… the public can be the end user. But to complete what I need for work it’ll be other devs in my department.

Depending on how complex you need the transform to be. You can as go as far as including a script to execute as part of the fetcher config in the update event. But you need that to be super secure - to avoid code injections You can try something like EBPF, or if you need just data extraction - maybe something like regex or glob pattern would be enough

I might be over-complicating this for our case.

Could be too 😉