Unable to assign VM/Device in one site to cluster that has no site

[jon-nfc]

Deployment Type

Self-hosted

NetBox Version

v3.7.5

Python Version

3.11

Steps to Reproduce

1. create vm/device and assign it to a site
2. create a cluster, don't assign any site
3. attempt to assign the created device/vm in step 1 to the cluster

Error message The selected cluster (<cluster name>) is not assigned to this site (<site name>)

Expected Behavior

If a cluster has no site set, then a VM/device from any site should be assignable to it. Without being able to do this, it's not possible to track a cluster that spans multiple DC.

Observed Behavior

Can't assign a device/vm with a defined site to a cluster with no defined site (null)

[nopg]

I'm looking for 'easy' first bug fixes to help with for NetBox. This issue appears to have been accepted, so does that mean the powers-that-be are good with allowing VM's assigned to a Site to be associated with a Cluster that doesn't have a Site?

Seems fairly basic, I'm just wondering if and how I could help. Looks like a simple tweak to:

netbox/netbox/virtualization/models/virtualmachines.py

Line 181 in 3c3943c

if self.cluster and self.site and self.cluster.site != self.site:

.

Should it only be allowed for Clusters without a Site assigned, should Clusters be allowed to be assigned to multiple Sites, etc?

[jon-nfc]

Should it only be allowed for Clusters without a Site assigned, should Clusters be allowed to be assigned to multiple Sites, etc?

A Cluster, like in my case can span the globe. Different providers in different regions. The VM's that the cluster runs on, in this case kubernetes do have a site, being their DC.

[nopg]

I can submit a PR allowing device/vm's with a site, to be assigned to a non-site cluster as described above, if allowed :)

[jon-nfc]

I can submit a PR allowing device/vm's with a site, to be assigned to a non-site cluster as described above, if allowed :)

Don't know what this allow business is? Generally with Open Source projects, you raise the PR and submit. That's generally the only time you'll have input. Obviously I'm all for the issue being fixed!!

[nopg]

I'm new here but I believe I have to be assigned to the issue before I can/should submit the PR. I have it ready to submit (diff at link below), it appears Devices already have this logic, so I updated VM's to match, added a new test for VM's, and all the similar tests to Devices since they didn't already exist.

https://github.com/netbox-community/netbox/compare/develop...nopg:netbox:15717-vm-cluster-site?diff=split&w=

[jon-nfc]

I believe I have to be assigned to the issue before I can/should submit the PR

Where'd that come from? If that's the policy to contribute to this repo, I can't imagine anyone coming back, let alone starting in the first place. 2-3 days avg turn around, it'd be a week before you even had the PR started. All that time wasted just for a line of code. When in the end all that is needed is to submit the PR, if it's not good to go, it'll be denied.

[peteeckel]

Where'd that come from? If that's the policy to contribute to this repo, I can't imagine anyone coming back, let alone starting in the first place. 2-3 days avg turn around, it'd be a week before you even had the PR started. All that time wasted just for a line of code. When in the end all that is needed is to submit the PR, if it's not good to go, it'll be denied.

It comes from the maintainers of NetBox.

NetBox is an enterprise grade piece of software that has many applications in business critical environments, and the process of handling PRs is their chosen way to control the direction the development takes. In the environments NetBox is used in speed is definitely not the first priority, but stability and maturity are.

On the other hand it's also a way to keep people from investing unnecessary work in PRs that eventually wouldn't be accepted anyway, so don't just see it as a random act of bureaucracy.

[jeremystretch]

@jon-nfc please take some time to read our contributing policy. These policies have been put in place to protect everyone's time. If you find yourself unable or unwilling to abide by it, please respectfully refrain from engaging with the project.