Container fixes

[troglobit]

Description

• Add validation of interface name length, Linux limitation (2 .. 15 chars)
• Add support for http/https/ftp URI:s in container image directive #801
• Fix Container environment variables do not bite in container #822
• Fix Updating embedded OCI image does not update container #823
• Improve robustness of execd with a timer callback while the queue is non-empty
• Simplify container creation and activation of changes at runtime
• Silence log (debug) messages from container helper script, retain podman create command

Note

Everyone, some helpful highlighting (like this one!) has been added to containers.md and networking.md, please review. See available highlights here -> https://github.com/orgs/community/discussions/16925

Checklist

Tick relevant boxes, this PR is-a or has-a:

• Bugfix
  • Regression tests
  • ChangeLog updates (for next release)
• Feature
  • YANG model change => revision updated?
  • Regression tests added?
  • ChangeLog updates (for next release)
  • Documentation added?
• Test changes
  • Checked in changed Readme.adoc (make test-spec)
  • Added new test to group Readme.adoc and yaml file
• Code style update (formatting, renaming)
• Refactoring (please detail in commit messages)
• Build related changes
• Documentation content changes
  • ChangeLog updated (for major changes)
• Other (please describe):

[jovatn]

I have only looked at documentation changes (container.md and networking.md). Looks great! Found two typos as commented above.

[mattiaswal]

HUGE refactor, great work! 🚀
I just have some small comments.

[wkz]

Mightily impressed! Really great work!

🎉 🎉 🎉

[wkz]

Maybe a pattern to tighten up the allowed inputs?

If we call the leaf sha256sum, we could more easily add other algorithms in the future (potentially we could wrap it in a choice as well)

[troglobit]

True, that would be better, I'll have a look!

[troglobit]

Proposal:

      container checksum {
	description "Checksum for ftp/http/https OCI archives.";
        choice checksum {
          leaf md5 {
            description "MD5 checksum for the archive.";
            type string {
              length "32";
              pattern "[a-fA-F0-9]{32}";
            }
          }

          leaf sha256 {
            description "SHA256 checksum for the archive.";
            type string {
              length "64";
              pattern "[a-fA-F0-9]{64}";
            }
          }

          leaf sha512 {
            description "SHA512 checksum for the archive.";
            type string {
              length "128";
              pattern "[a-fA-F0-9]{128}";
            }
          }
        }
      }

Just learned that case is optional in YANG 🤯

This will get a CLI session like this:

admin@example:/config/container/web> set image ftp://host/archive.tar.gz
admin@example:/config/container/web> set checksum sha256 asdsadsadsadsadsa

[wkz]

Nice! That looks great 👍

[wkz]

text-editor seems a bit too generic for what this does, no? sr-bin-edit? Even in a future where admin/exec is implemented in bash, users would still use something like today's CLI for the config context, right? There text-editor can be YANG-type-aware version, i.e., handle binaries, strings, lists etc.

[troglobit]

Sure thing, was aiming for recognition between CLI and shell, but you're right it's too generic in this case. (Unlike, e.g., the copy command for instance.)

Not sure about the name sr-bin-edit though.

[troglobit]

After some discussions in another forum we decided on the following:

• Convert the cfg alias into a shell script,
• Add verb cases in a case/esac for operations like:
  • edit: to edit binary nodes
  • import/export: to workaround sysrepocfg's oddities in the option parser
  • copy: between datastores
• with a default case that falls back to the old exec sysrepocfg -f json "$@"

[wkz]

"survive" tripped my swinglish-detector. Maybe something like:

at every boot. When non-volatile storage is needed, data stored in volumes will be persisted until explicitly removed from the configuration, i.e., across host and container reboots and upgrades.

Re: content mounts: are they really "truly persistent"?

[troglobit]

"survive" tripped my swinglish-detector. Maybe something like:

at every boot. When non-volatile storage is needed, data stored in volumes will be persisted until explicitly removed from the configuration, i.e., across host and container reboots and upgrades.

Much better, thanks!

Re: content mounts: are they really "truly persistent"?

Well it's the content data stored in startup-config ... ? But I can try to find a better wording.

[troglobit]

Did this:

The second creates a read-only container that is automatically started
at every boot. When non-volatile storage is needed, data stored in a
volume is persisted until explicitly removed from the configuration,
i.e., across host and container reboots and upgrades.

Another option is Content Mounts, where the content
of a file mounted into the container is kept along with the container
configuration in the device's startup-config.