Thoughts and feedback regarding configurability

[skurfuerst]

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 :)

[NHAS]

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.

[skurfuerst]

With configuration Im assuming you're primarily meaning groups and acls?

Yes, Groups, ACLs, and everything you find in the "settings" tab (overridden from CLI settings I'd say).

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.

I am unsure, couldn't we just use https://etcd.io/docs/v3.5/tutorials/how-to-transactional-write/ to atomically replace the ETCD store?

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?

I am running WAG in a really simple docker-compose setup, with caddy for TLS (could be also included in WAG in the medium term, but then there would need to be a solution for different ACME-DNS providers); and unbound as DNS resolver.

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.

No worries, you don't have any obligation to push this forward :) I just felt that I wanted to start thinking about this, and sync with you on this topic - so it might be I start working into the above direction. But I also have lots of things on the TODO list, so also unsure when I will work on this :-)

P.S on the DNS front, ...

totally understandable - thanks for your guidance :)

[NHAS]

The problem isnt automatically replacing things in the db thats easy. Its more working out what to replace, how to make sure the replacement syncs from db -> reality safely and rolls back if it doesnt.

All while not doing a delete -> replace as that would cause traffic to fail for a period of time.

Replacing the settings in the settings page is much harder than doing the groups and acls as they're already nicely packaged up to do that, and already have a diff like structure. But I'll think about it!

[skurfuerst]

I see :) But for settings, can't this be either done only on startup, or in the same manner as if changing settings in the UI? (Maybe I am naive, but afaics lots of the pieces are already there :-) )

[NHAS]

It's a bit hard to have the config be loaded in, and then also changable from the management UI just from a design perspective as then its both static and dynamic at the same time.

There is probably a decent way to do this but I'll have a think. I can probably get an acls & groups poc up soonish if I have time

[NHAS]

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.
But for more in depth configurations, like changing the authentication methods perhaps not.