Thoughts and feedback regarding configurability #242
Replies: 2 comments 4 replies
-
|
Howdy! These are good thoughts. I think having some level of gitops ability would be very nice. With configuration Im assuming you're primarily meaning groups and acls? Splitting out just the acls & groups from the config file then doing something that allows us to post to an endpoint would be very nice for that. The hardest part will be doing diff resolution between the current state and the expected state so we don't have to just wipe the config (causing a small outage window) to reapply it. If you run through how your gitops setup is for everything else I can have a better think about it. Are you running wag in a k8s cluster, container or bare metal? It is worth nothing that my time is a little constrained as I've got a fair amount of work going on outside of this. P.S on the DNS front, I've thought about this in the past when it came to solving some internal acme challenges at a business where wag was deployed. However that would require a lot of extension of the wag project, more UI, and exceeds the scope of what I want wag to be, so I'm going to shut that down unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly using this: https://pkg.go.dev/github.com/wI2L/jsondiff To generate a list of ops from a modified json blob that is posted to an API endpoint. I'd be happy to mock up an acls/groups version of this and a flag to disable editing those from the management web UI. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey @NHAS ,
after running WAG now for about a month, I am generally really really happy with the tool. It does work exactly as advertised, and I very much like it :-)
There is one topic, where I am a bit unsure: I personally run our full infrastructure via Ansible in a GitOps way (so everything is controlled from Ansible). For the initial config of WAG, this works fine (ansible simply writes
config.json), but now the primary config is mostly in etcd and not in the config file. I understand why this might be useful for HA setups, though it does not really fit my use case so well.For me it was difficult to see which config settings are directly applied from the config files, and which are only imported into etcd. Maybe it also would be an option to say "force reimport from config" at startup - to reduce configuration drift? So basically changing https://github.com/NHAS/wag/blob/main/internal/data/init.go#L362 based on a flag which then forces to import from config file to etcd?
I feel this process of "Config File -> etcd -> reading from etcd" is still a bit complicated (and I am unsure when I need to introduce new etcd keys and when not), but I don't grasp the full consequences of this yet.
Curious about your thoughts 👍
Sebastian
PS: another idea - I was thinking of maybe integrating https://coredns.io/ directly into the server binary - this way, one could define DNS overrides directly in the config; and we could optionally redirect to the 2FA portal via DNS overrides. But I feel I need more understanding about the config handling first :)
Beta Was this translation helpful? Give feedback.
All reactions