On reflection, I think I'll take my comments on the network objects a little
further - I don't think that a separate object is needed here at all, and
believe that the configuration should be folded into the server (as
network.eth0.vlan, network.eth0.dhcp, etc.).

My logic is that API objects should only exist where something exists with
state which is persistent and independent of other objects.

server, drives, and ownership of resources such as static IPs or VLANs all
fulfill this.

Network configuration does not - essentially this is just configuration of a
network interface on a server. As such, it's much simpler to fold the
configuration into the server object itself, rather than splitting it out
into a separate "configuration object" and linking to it from the main
"server object".

Yup, been here too (I've been working on this problem for a while before getting suck into this).

For a public cloud like EH things are pretty simple - you just give an IP to a machine and away you go... they can talk to each other and if you must then you can pop a firewall/load balancer in front.

For anything more complex though you do need to keep track of your [virtual] networks separately, even if only because the client needs to be able to enumerate them in order to give the users something to strap their VMs to and (on the system management side) to link to a physical segment.

I'm not sure what really needs to be configured here beyond a label/description, but it's conceivable that a network management extension would be interesting for vendors like Cisco.

Sam