Add partial config file functionality to cEOS

[CapnCheapo]

by @hellt: the review comments have to be addressed and eval'ed

Added partial config support for cEOS modeled after how it's implemented in vIOS and other node types.

[hellt]

/cc @ankudinov

[ankudinov]

@CapnCheapo Thank you for submitting the PR.
Could you please add following to this PR:

1. Documentation explaining how partial config works. Similar to how it's done for other node types where partial config is supported.
2. Provide steps to test this PR before merging to reduce time required for reviewers to build the lab. @hellt I'd suggest to that as a requirement to Containerlab PR templates.

I'd appreciate if you provide a few use cases where this feature is critical. The motivation is clear in general, but I have a very strong opinion that Containerlab users should always provide a full startup config for every node instead of relying on defaults. This helps to avoid confusion in case of changes on EOS or Containerlab side and guarantees clean start of the lab. However I have a very specific workflow in mind where the full state of the lab is dictated by the Git repo. I imagine that for an average user that can be a useful feature. But would be great to see a few specific use cases where it's a must in the docs. With possible risks highlighted.

[CapnCheapo]

@ankudinov I have attached documentation updates and test cases. Let me know if anything should be updated.

As for critical use cases, I don't think any of this counts as "critical", more of "nice to have" functionality. I have been designing learning labs for users of all levels. It is very convenient to be able to add additional configuration onto a device baseline. I don't want my users to be focused on the management underlay of a lab, but rather the topic being presented. Using partial config, the user can quickly and easily see what has been configured on a device without worrying about how the lab itself is setup. From a maintainer standpoint, this requires much less config to be managed, as well. For more experienced users, this allows for them to cut the amount of time needed messing around with a default config and allows them to get straight to the topic at hand.

It is true that if EOS changes there might be some incompatibilities introduced, but this is not going to be the fault of a partial configuration feature. If something changes, both the standard template as well as any user-defined full configuration files will have to change. If anything, partial config support reduces the amount of config files that need to be changed. Plus, the user is free to override any erroneous config in the partial config as necessary.

Please let me know if you need more information or anything reworked. I am primarily an "old school" network engineer, not a developer, and this is my first major attempt at contributing to a software project, so i have much to learn.

[ankudinov]

According to a quick AI review for this PR new nodes/ceos/ceos.go logic no longer honors suppress-startup-config and enforce-startup-config. I was not checking the code in detail, but installed the Containerlab from you branch and tested following:

1. enforce-startup-config: false for cEOS kind
2. define startup-config for every cEOS node
3. Start the lab and change the hostname on one of the nodes (or do any other change)
4. Stop the lab WITHOUT --cleanup
5. Start the lab again and check the hostname: hostname is set from the startup config

This is breaking and must be fixed.

[ankudinov]

AI remark, not tested in the lab:
Full configs still get Go template rendering, but no longer pass through SubstituteEnvsAndTemplate, so ${VAR} expansion regresses. Partial configs are inserted as .PartialCfg, so a partial file containing {{ .ShortName }} would be emitted literally instead of rendered.

Please add a test case for env expansion.

[ankudinov]

Thank you for adding the test.
As it looks like this PR can break more than I anticipated originally, please also add tests for:

• startup config preservaion
• suppress-startup-config
• env expansion and template rendering inside partial config

Thank you!

[ankudinov]

@hellt and @CapnCheapo should we close this one?

[ankudinov]

@hellt and @FloSch62 Please use your admin rights to close this. =)

[hellt]

let me park it into the draft, I might be able to have a look at it