starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Ability to assign a Tenant to a Device Component #5644

New Issue
Closed
opened 2025-12-29 19:30:36 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:30:36 +01:00
Owner
Copy Link

Originally created by @erdems on GitHub (Nov 10, 2021).

NetBox version

v3.0.9

Feature type

Change to existing functionality

Proposed functionality

Add ability to assign a tenant to various device components, mainly:

  • Ports
  • Device Bays
  • Interfaces

Use case

In a Datacenter Provider environment, some host customer equipment and/or allocate / rent device bays to multiple tenants. A similar scenario goes in case of logical routers where one or more ports are allocated to a logical router that is left for the tenant to manage as they please.

Another scenario is the use of some security-related USB dongles where the provider essentially rents ports for tenant dongles. At the moment, netbox can't plan or keep track of those without potentially excessive use of tags with the same tenant slug. Even so, this approach won't make those ports/dongles/whatever show in tenant's summary page.

Database changes

Add a tenant_id field for device components, defaulting to NULL.

External dependencies

None.

Originally created by @erdems on GitHub (Nov 10, 2021). ### NetBox version v3.0.9 ### Feature type Change to existing functionality ### Proposed functionality Add ability to assign a tenant to various device components, mainly: * Ports * Device Bays * Interfaces ### Use case In a Datacenter Provider environment, some host customer equipment and/or allocate / rent device bays to multiple tenants. A similar scenario goes in case of logical routers where one or more ports are allocated to a logical router that is left for the tenant to manage as they please. Another scenario is the use of some security-related USB dongles where the provider essentially rents ports for tenant dongles. At the moment, netbox can't plan or keep track of those without potentially excessive use of tags with the same tenant slug. Even so, this approach won't make those ports/dongles/whatever show in tenant's summary page. ### Database changes Add a tenant_id field for device components, defaulting to NULL. ### External dependencies None.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:30:36 +01:00
adam closed this issue 2025-12-29 19:30:36 +01:00
adam commented 2025-12-29 19:30:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 11, 2021):

This doesn't make any sense to me. Tenancy in NetBox implies ownership. It's not practical to have multiple tenants own different parts of a device. I'm afraid you're trying to extend the concept of tenancy beyond its intended purpose. It seems like tags and/or custom fields would better serve your use cases.

@jeremystretch commented on GitHub (Nov 11, 2021): This doesn't make any sense to me. Tenancy in NetBox implies ownership. It's not practical to have multiple tenants own different parts of a device. I'm afraid you're trying to extend the concept of tenancy beyond its intended purpose. It seems like tags and/or custom fields would better serve your use cases.
adam commented 2025-12-29 19:30:37 +01:00
Author
Owner
Copy Link

@erdems commented on GitHub (Nov 12, 2021):

Understood. However, especially in case of Blade Chassis or GNF or similar devices that support the concept of multi-tenancy within a single chassis, a tenant is solely and directly allocated a blade or a logical router, for instance. Although I understand this may not imply ownership in the generic sense of netbox, as in the tenant can't come and collect that linecard etc., that particular part/component still is theirs in terms of usage and management.

Do you think it would make sense to enhance the tenant's page to include / report custom fields or tags? IMHO, this would complicate things more.

@erdems commented on GitHub (Nov 12, 2021): Understood. However, especially in case of Blade Chassis or GNF or similar devices that support the concept of multi-tenancy within a single chassis, a tenant is solely and directly allocated a blade or a logical router, for instance. Although I understand this may not imply ownership in the generic sense of netbox, as in the tenant can't come and collect that linecard etc., that particular part/component still is theirs in terms of usage and management. Do you think it would make sense to enhance the tenant's page to include / report custom fields or tags? IMHO, this would complicate things more.
adam commented 2025-12-29 19:30:37 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 15, 2021):

Understood. However, especially in case of Blade Chassis or GNF or similar devices that support the concept of multi-tenancy within a single chassis, a tenant is solely and directly allocated a blade or a logical router, for instance. Although I understand this may not imply ownership in the generic sense of netbox, as in the tenant can't come and collect that linecard etc., that particular part/component still is theirs in terms of usage and management.

In a blade or chassis configuration, the chassis should be modeled separately from the the blades. The chassis should be owned by the provider (you) and the tenant shoudl be the owner of the blade which is slotted into one of the bays within the chassis. ONAP/GNF, you should probably be modelling as a virtual device with the appropriate tenant defined.

@DanSheps commented on GitHub (Nov 15, 2021): > Understood. However, especially in case of Blade Chassis or GNF or similar devices that support the concept of multi-tenancy within a single chassis, a tenant is solely and directly allocated a blade or a logical router, for instance. Although I understand this may not imply ownership in the generic sense of netbox, as in the tenant can't come and collect that linecard etc., that particular part/component still is theirs in terms of usage and management. In a blade or chassis configuration, the chassis should be modeled separately from the the blades. The chassis should be owned by the provider (you) and the tenant shoudl be the owner of the blade which is slotted into one of the bays within the chassis. ONAP/GNF, you should probably be modelling as a virtual device with the appropriate tenant defined.
adam commented 2025-12-29 19:30:37 +01:00
Author
Owner
Copy Link

@erdems commented on GitHub (Nov 15, 2021):

Thanks Dan; indeed I agree blade/chassis configuration could (and possibly should) be handled that way. In case of a GNF for instance, the 'router' is in fact one or more line-cards that are often leased to the tenant but sometimes even owned by them. There's also the case of USB dongles plugged to an UTN device where the dongles literally belong to the tenant. I guess it would be possible to treat the dongles as devices slotted in the ports, I'll give this a try.

Still, GNF's case looks problematic to me, maybe I'm missing a point.

@erdems commented on GitHub (Nov 15, 2021): Thanks Dan; indeed I agree blade/chassis configuration could (and possibly should) be handled that way. In case of a GNF for instance, the 'router' is in fact one or more line-cards that are often leased to the tenant but sometimes even owned by them. There's also the case of USB dongles plugged to an UTN device where the dongles literally belong to the tenant. I guess it would be possible to treat the dongles as devices slotted in the ports, I'll give this a try. Still, GNF's case looks problematic to me, maybe I'm missing a point.
adam commented 2025-12-29 19:30:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 15, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 15, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:30:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 14, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Feb 14, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5644
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?