Support the assignment of virtual machines as cluster hosts

[candlerb]

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 3.5.2
• NetBox version: v2.2-beta1

Description

A VM runs on pool of resources called a "cluster". At the moment, a cluster can only consist of physical devices. I would like a cluster to have VMs as hosts too [^1]

Use cases:

• You run a number of lxd containers inside an lxd server, which itself is a VM.
  • "container1.example.com" is an lxd container
  • It runs insides a VM called "lxd1.example.com"
  • The host VM "lxd1.example.com" in turn runs on a virtualization cluster made up of physical devices
  • So this could be modelled as:
    • "container1.example.com" is a VM running on cluster "lxd1"
    • "lxd1" is a cluster of type "lxd", with member devices (VMs) "lxd1.example.com"
    • "lxd1.example.com" is a VM running on cluster "main"
    • "main" is cluster of type "vSphere" with member devices (physical) X, Y, Z
    • note that cluster "lxd1" could comprise multiple VMs; that is, lxd containers can be migrated between lxd hosts
• You run docker containers inside a third-party cloud
  • you fire up a VM inside a cloud
  • you run docker on that VM
  • inside that VM you run multiple docker containers
    • So our cluster "mydocker" has member "docker1.example.com" which is a cloud VM, not a physical device
    • The cloud VM is a member of a cluster called "EC2 (eu-west)" or suchlike.

---

[^1] It would probably be OK if a cluster were limited to take either physical devices or virtual machines; that is, you have to select "physical cluster" or "virtual cluster".

That might make the UI less confusing, although it blocks the (relatively unusual) case of a mixed cluster.

[jeremystretch]

I looked into this possibility while fleshing out the initial data model and it's just a nightmare to implement. The VirtualMachine model already has a foreign key to the Cluster model to indicate assignment as a VM. Adding a second relationship between the two introduces a whole slew of validation issues: preventing a VM from hosting its own cluster, preventing infinite recursion, preventing physical devices from hosting Docker-based clusters, etc.

NetBox's role is as an IPAM/DCIM application and I believe the model introduced in the beta has satisfied that role. You can still create VM-based clusters and track IP assignments to Docker containers, you just can't model the assignment of VMs as cluster hosts. (The assignment of hosts to a cluster is optional.) IMO this is a reasonable compromise and keeps us from creeping into VM orchestration territory, for which most organizations will use a separate tool anyway.

[candlerb]

OK, understood.

Many objects in Netbox have either "description" or "comments" field. How about adding one to Cluster? Then such cases can be documented ad-hoc.

[jeremystretch]

Fixed the comments field on the Cluster object in #1514

[snowie-swe]

I looked into this possibility while fleshing out the initial data model and it's just a nightmare to implement. The VirtualMachine model already has a foreign key to the Cluster model to indicate assignment as a VM. Adding a second relationship between the two introduces a whole slew of validation issues: preventing a VM from hosting its own cluster, preventing infinite recursion, preventing physical devices from hosting Docker-based clusters, etc.

NetBox's role is as an IPAM/DCIM application and I believe the model introduced in the beta has satisfied that role. You can still create VM-based clusters and track IP assignments to Docker containers, you just can't model the assignment of VMs as cluster hosts. (The assignment of hosts to a cluster is optional.) IMO this is a reasonable compromise and keeps us from creeping into VM orchestration territory, for which most organizations will use a separate tool anyway.

@jeremystretch
This feature would also be very handy for virtual appliances like Loadbalancers and Firewalls.
Worth checking in to again? as more and more infrastructure become virtual.