netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Public demo: https://demo.netbox.dev
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.44k stars 2.52k forks source link

Allow Virtual Machines to be Grouped outside of Clusters #14915

Open KjellWolf opened 5 months ago

KjellWolf commented 5 months ago

NetBox version

v3.7.0

Feature type

Data model extension

Proposed functionality

We would like to be able to group virtual machines, outside of a cluster definition. We create "projects" ourselves or for our tenants, as several projects can originate from one tenant, as well as other contacts.

The suggestion would therefore be to create a "VM Groups" section under "Virtualisation > Virtual Machines". options: Main:

Resources:

every other customisation we need is handled with the customisation options already provided

Use case

As mentioned, there are often projects that require a logical combination of VMs in one view, but do not form a cluster as such.

This simplifies the view of which servers belong together to the corresponding customer order and who is the contact person at the customer or internally for the project.

Database changes

No response

External dependencies

No response

jeremystretch commented 5 months ago

It sounds like tags or a custom field would work well for this purpose.

KjellWolf commented 5 months ago

Tags and custom flields do not have the Options we need all at once. We need this as seperate pages to sort in other custom flields we already use Like Docs.

It wouldnt give us the clarity of all information we need at once

jeremystretch commented 5 months ago

Sorry, what specific functionality are you looking for that wouldn't be possible?

KjellWolf commented 5 months ago

When I search for a tenant under Related Objects, I can see Projects/VM Groups there.

When I click on the group I have a window with the related VMs and the other information I specified and see only the objects I need.

We would add a link field to our documentation for this project and customer specific contacts for this VM group.

I cloud hijack the cluster groupings for this, I know, but a separate entry would be better in our opinion.

stavr666 commented 5 months ago

Cluster Type / Cluster Group / Cluster works (almost) perfectly for similar cases:

image

Yes, the "cluster" terminology looks confusing for actual projects/tenants/orgs/groups in clouds or containerized deployments (and in some cases, there is missing actual infrastructure context, like assigned VMs for deployments, or multisite structure), but it's still usable for described scenario.

KjellWolf commented 5 months ago

@stavr666 yes, I mentioned it. But it's then it's like you said confusing and not every time applicable. more so with staff in training.

I still pitched this as an Idea to my management.

uppsju commented 5 months ago

Would an alternative be to use Tenant Groups? E.g for each client you have, you create a separate tenant group. Then you could create one tenant for each project for that customer.

jeffgdotorg commented 3 months ago

@KjellWolf I'm triaging some backlogged issues and came across this one. Did @uppsju's suggestion of fielding Tenant Groups to achieve your aim pan out? If so, please close the issue. If not, please make revisions to your original issue body addressing the shortcomings of Tags, Custom Fields, and Tenant Groups.

arthanson commented 2 months ago

@KjellWolf any feedback on the above suggestion from uppsju? I will close this soon if no feedback.

KjellWolf commented 2 months ago

While Tenant Groups could be an option, they may not perfectly fit your Client > Project > VM structure, especially with multiple clusters and loose VM groups. The proposed "VM Groups" section offers a more tailored solution. It allows for granular organization, independent of clusters, reflecting your project hierarchy effectively. This ensures seamless management and clarity in customer orders and internal coordination.

jeremystretch commented 2 months ago

I'll tag this as "needs milestone" for potential future implementation.