Code Refactoring Idea -- NodeConfig/NodeDefinition/GenericContainer

[networkop]

Hi, I wanted to float a few ideas by you, to see if you're interested. Today, we have 3 types (NodeConfig/NodeDefinition/GenericContainer) representing a single object -- container. This means some values are copied between fields back and forth in different parts of the code and this leads to bugs and reduced readability. So I thought, wouldn't it be nice to have a single type, e.g. api.Container that would contain both configuration state (name, kind, image) as well as the operational state (runtime, containerID)?

As a side note, this is how all k8s APIs are designed -- with metadata fields (name, labels), spec fields containing configuration data and status fields containing any pertinent runtime information. There are projects like api-machinery that can automate a lot of work based on some input in the form of go structs shaped as your desired API object. Using this approach we'd get additional benefits like:

• Automatic schema file generation (openapi)
• API versioning to avoid backwards-incompatible changes
• Boilerplate client code to interact with API objects

wdyt?

[hellt]

I'd like to see this in action, if you can come up with a poc code?

on the naming side, would it make more sense to call it api.Node? As we will have non container nodes such as bridges, hosts, etc