customize: Add --network-nmstate option

[qinqon]

It's possible to generate NetworkManager keyfiles from a Nmstate
configuration. This change add a new option to use Nmstate format
instead of multiple NetworkManager keyfiles to specify network
configuration.

The output from nmstate gen_conf is a HashMap of backend name to nmconnection vectors with the following format

NetworkManager:
  - "[connection]\nautoconnect=true\nautoconnect-slaves=-1\nid=dummyfoo\ninterface-name=dummyfoo\ntype=dummy\nuuid=157d8614-c3bd-4a10-9330-310fcf692468\n\n[ipv4]\nmethod=disabled\n\n[ipv6]\nmethod=disabled\n"

One call to gen_conf can dump multiple keyfiles from the "NetworkManager" backend.

[jlebon]

Cool, thanks! Assuming getting the deps right in Fedora isn't too much work, this SGTM. I think even if we end up doing coreos/fedora-coreos-tracker#1175, this still has value because it allows configuring the network in the initramfs of the live system too using NMState files.

[bgilbert]

This is great, thank you!

[qinqon]

Testing part is not fixed yet, but code is reviewable now.

[qinqon]

Cargo.toml has now a pin to nmstate/nmstate#1915, test should pass, but this cannot be merged until the PR is merge and nmstate published to cargo.io.

[qinqon]

@bgilbert fixed clippy issues.

[qinqon]

Hey @qinqon Looks like fedora 36 update is ready at https://bodhi.fedoraproject.org/updates/FEDORA-2022-b78be96657
But the coreos-install build RPM need to add requirements (crate(nmstate/default) >= 2.1.2 with crate(nmstate/default) < 3.0)

[bgilbert]

Rust package requirements are automatically added by rust-srpm-macros.

[qinqon]

@bgilbert Do you know what happening with CI ?

[bgilbert]

Do you know what happening with CI ?

kola basic tests are failing with ENOSPC. I'm checking whether it's a broader issue.

[bgilbert]

The MSRV tests should be fixed by #926. The RPM test is awaiting FEDORA-2022-b78be96657 going stable.

[bgilbert]

I'm not seeing that ENOSPC error in other PRs.

[bgilbert]

Could you try rebasing? That should fix the GitHub Actions checks, and we can see whether it fixes the kola failure too. If it doesn't, there may be an actual problem with the PR.

[jlebon]

I think @bgilbert and I came to the same realization in parallel. :) I suspect CI is hitting ENOSPC because rdcore includes debuginfo and we're not using LTO in debug mode so it's including nmstate. But even without this change, I think we should probably strip the binary when installing it in debug mode like CI does. Did that in #929.

[bgilbert]

We're testing with 1 GB of RAM, and this PR increases the rdcore size from 132 to 178 MiB.

(Actually we're not using LTO at all anymore; it was too buggy.)

[bgilbert]

Confirmed that #929 fixes the ENOSPC.

[qinqon]

We're testing with 1 GB of RAM, and this PR increases the rdcore size from 132 to 178 MiB.

(Actually we're not using LTO at all anymore; it was too buggy.)

Do we have to do something at nmstate to reduce rdcore size ? or 178 is ok ?

[bgilbert]

No, the rdcore binary is only about 2 MiB with all symbols stripped, or 6 MiB with debug symbols stripped. That's what we actually ship in the OS, so this is only a CI problem. We'll just land #929 and then you can rebase on top of it.

[bgilbert]

Okay, if you rebase this on main it should fix CI.

[bgilbert]

Thanks for all your work on this! 🎉 🎈 🎆