@guelfey PTAL

Generally makes sense, however I'd like to stick to the GVariant format from GLib since this seems to be the convention for other tools, and DBus structs are called "tuples" there: https://www.freedesktop.org/software/gstreamer-sdk/data/docs/2012.5/glib/gvariant-text.html#gvariant-text-tuples ar the best docs I can find. So normal parantheses and separating the field with a comma.

@guelfey ok thanks for the feedback. I wasn't sure what the format should be so I'll repush with those changes tonight.

@giuseppe, using this PR in c/common the unit file generated looks like

# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=cgroup machine2-libpod_pod_105.slice
Wants=machine2.slice
DefaultDependencies=no

[Slice]
MemoryAccounting=yes
CPUAccounting=yes
IOAccounting=yes
CPUWeight=4
MemoryMax=900
MemorySwapMax=1000
CPUQuotaPeriodSec=100ms
CPUQuota=100%
AllowedCPUs=4-5
AllowedMemoryNodes=4-5
IOReadBandwidthMax=
IOReadBandwidthMax=8:16 2097152

which is incorrectly adding an extra blank line, nothing is being added to io.max. The final property being provided is {IOReadBandwidthMax [("8:16", 2097152)]} does this seem right to you? not sure where to go from here.

how does the generated value you pass to systemd look like? Not sure if the empty io.max depends on that extra empty line

@giuseppe running something like:

...
for k, v := range structMap {
			vari := dbus.MakeVariant(v)
			fmt.Println(vari.Signature(), vari.String(), vari.Value())
...

prints:

a(st) @a(st) [("8:16" 2097152)] [{8:16 2097152}]

as a matter of fact, the extra lines are added to the unit file even without these modifications...

@guelfey this should be good to go! works with my PR in containers/common

@guelfey sorry I took so long here. To answer your question about why this is needed, mainly for testing and verification that systemd is getting the right values before we merge something into containers/common. Otherwise, debug statements just print INVALID

Hey, @cdoern -- is this going anywhere? I am interested in the fork of routerd/go-firewalld but it seems that work is blocked on merging this? @grmrgecko ?

@rschmied I don't think it blocks my PR, but there are 4 methods I implemented that will not work until this is done. Upstream of go-firewalld hasn't responded about my changes, but you can use it with the following added to the go module file.

replace github.com/routerd/go-firewalld => github.com/grmrgecko/go-firewalld

If routerd doesn't respond, I wouldn't mind changing the module file in my fork to allow people to just use it without the replace declaration.

Thanks for this. I'd be fine with using your fork but then there's still the additional dependency on this, right? E.g. I'd have to use two unmerged PRs / different forks to get the whole functionality (the additional 4 methods plus the required dbus support) , right?