organizational models and many-to-many relationships?

[pisaniej]

Hi there,

If I want to create an 'owner' model within the Organizational models, would I be able to assign many 'owner' entries to many primary models?

e.g.

owner1 and owner1 (dcim.Owner) belong to vm1, vm2, ... (dcim.Device) & device1, device2,, ... (virtualization.VirtualMachine)

note that for my use case this is essentially 'tenant', but with the ability to assign multiple tenants to a single device/vm (tenant groups do not work here since it would be nearly impossible to manage at that scale)

thanks

[candlerb]

"Tenant" is single-valued. I think the better fit for you here is to use Tags to represent owners.

[pisaniej]

Right, which is why I'm choosing not to extend/modify/copy 'Tenant' to a new model.

While tags would be nice, I need some additional data about each 'Owner', which is why I really wanted to implement another model.

[candlerb]

You could define tags like tenant_xxx where xxx is the slug for a particular tenant, and store the rest of the data in the main Tenant model. You'd just need a process so that whenever you create a new Tenant, you also create a corresponding new Tag. You can use a Custom Script to do that, or a webhook trigger.

Custom fields with multi-valued selections might work instead of tags. This feature was added in Netbox v2.11.0 - #5451 - although I've not tried it myself. Your list of owners will be defined statically. But like tags, the owners won't have their own attributes (unless they are just aliases for tenants).

Tenant groups might work, but I don't know your business requirements. It seems unusual that a given device or VM could have an arbitrary selection of "owners" associated with it.

Otherwise, possibly what you want can be achieved by writing a plugin with your own "owner" model and a many-to-many join.

[pisaniej]

That's good information, thanks.

Ultimately the business use case is that any given server (vm or device) can be owner by 1 or more entities (which can be either and individual or a group).

I'm trying to cover the current case where a server is 'owned' by more than one group (yes, it happens), or that the server is 'owned' by two individuals from different groups.

Tenant groups don't scale for this use case since the can range from a single user up to any combination of N users and M groups.

I think the best route here is to write a custom plugin with my desired model. I also need to custom functionality of validating new 'owner' names against entries within LDAP.

[candlerb]

Ultimately the business use case is that any given server (vm or device) can be owner by 1 or more entities (which can be either and individual or a group).

In the way you've written it, that's not a business requirement: that's a technical requirement.

What I mean is, what is the business-visible effect of setting an "owner" on a device in Netbox? Do you want it to grant permissions in the Netbox UI/API to see and/or modify the device? Does it mean they will receive alerts when that device goes down? Will it be used for apportioning the running costs of the device between business units? Something else?

[pisaniej]

In the way you've written it, that's not a business requirement: that's a technical requirement.

Touché, yes.

In no way would setting an "owner" do anything to the device/object in question. This is merely to track who should be contacted in case of retirement, maintenance, etc. Ideally the "owner" object would contain multiple fields providing a name, email, phone number, etc.

For example, here is a rough mock up of virtualization.virtualmachine implemented with dcim.owner:

Clicking on First Last under Owner(s) for that virtualization.virtualmachine object would bring you to the associated dcim.owner page:

The groups within the right-side Stats page (similar to "Tenants") would show you all objects associated with that dcim.owner.

All that being said, I think the proposed/upcoming feature of a "Contact" object would satisfy this requirement. There's still must discussion to be done there it seems.

[DanSheps]

Just want to pop in here and let you know to be very hesitant to do anything around owners/contacts/etc as that could very well be something we introduce down the road and if you deploy it as a plug there is a very good chance the data won't be compatible or it could break when migrating.

[pisaniej]

Understood, thanks for your response. I see that there's some traction here.