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

Add Support for Tenant Associations for Power Feeds/Panels #7883

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

Originally created by @djmelik on GitHub (Apr 8, 2023).

Originally assigned to: @abhi1693 on GitHub.

NetBox version

v3.4.7

Feature type

Data model extension

Proposed functionality

I would like to request support for native tenant association for Power Feeds and Power Panels. Currently, I am having to rely on Custom Fields to achieve this functionality which seems more of a "hack" when given that every other Object ie. Circuits, Racks, Locations, Sites, Prefixes, ASNs, etc. within Netbox has native tenant association.

I think this change would further polish the Netbox DCIM/IPAM platform; by promoting greater consistency and standardization. Currently, it feels like the the Power objects are incomplete and not as polished as the rest.

It would also be nice to add Power Feeds under the stats section on the Tenant Page.

Use case

It would allow users to natively associate and assign power feeds/panels to their respective tenants.

Database changes

Unfortunately, I am not a developer and I do not know how to meaningfully answer this. Thank you for your consideration!

External dependencies

N/A

Originally created by @djmelik on GitHub (Apr 8, 2023). Originally assigned to: @abhi1693 on GitHub. ### NetBox version v3.4.7 ### Feature type Data model extension ### Proposed functionality I would like to request support for native tenant association for Power Feeds and Power Panels. Currently, I am having to rely on Custom Fields to achieve this functionality which seems more of a "hack" when given that *every* other Object ie. Circuits, Racks, Locations, Sites, Prefixes, ASNs, etc. within Netbox has native tenant association. I think this change would further polish the Netbox DCIM/IPAM platform; by promoting greater consistency and standardization. Currently, it feels like the the Power objects are incomplete and not as polished as the rest. It would also be nice to add Power Feeds under the stats section on the Tenant Page. ### Use case It would allow users to natively associate and assign power feeds/panels to their respective tenants. ### Database changes Unfortunately, I am not a developer and I do not know how to meaningfully answer this. Thank you for your consideration! ### External dependencies N/A
adam added the status: acceptedtype: feature labels 2025-12-29 20:29:30 +01:00
adam closed this issue 2025-12-29 20:29:30 +01:00
adam commented 2025-12-29 20:29:31 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Apr 10, 2023):

Quick questions:

Do you often have multiple different tenants per rack with their own dedicated Power?
How many different Power Panels of different tenancy do you intent to model ?

@jsenecal commented on GitHub (Apr 10, 2023): Quick questions: Do you often have multiple different tenants per rack with their own dedicated Power? How many different Power Panels of different tenancy do you intent to model ?
adam commented 2025-12-29 20:29:32 +01:00
Author
Owner
Copy Link

@djmelik commented on GitHub (Apr 14, 2023):

Hi @jsenecal,

To your questions:

Do you often have multiple different tenants per rack with their own dedicated Power?

We do not have multiple different tenants per rack with their own dedicated power. Power feeds are generally always provisioned to a single tenant, and in instances of shared racks and shared power, the rack and feed are assigned to our organization (we have a tenant objecting reflecting our organization for all internal resources).

How many different Power Panels of different tenancy do you intent to model ?

I advised to also extend tenancy to power panels for consistency and standardization. That said, I did come to learn that we do have two entire power panels dedicated to two different organizations. For our Netbox instance, if this feature request is approved, most panels will be assigned to our organization; and the feeds themselves will be further organized into downstream tenants.

Please let me know if my answers are reasonable.

@djmelik commented on GitHub (Apr 14, 2023): Hi @jsenecal, To your questions: >Do you often have multiple different tenants per rack with their own dedicated Power? We do not have multiple different tenants per rack with their own dedicated power. Power feeds are generally always provisioned to a single tenant, and in instances of shared racks and shared power, the rack and feed are assigned to *our* organization (we have a tenant objecting reflecting our organization for all internal resources). >How many different Power Panels of different tenancy do you intent to model ? I advised to also extend tenancy to power panels for consistency and standardization. That said, I did come to learn that we do have two entire power panels dedicated to two different organizations. For our Netbox instance, if this feature request is approved, most panels will be assigned to our organization; and the feeds themselves will be further organized into downstream tenants. Please let me know if my answers are reasonable.
adam commented 2025-12-29 20:29:32 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Apr 14, 2023):

Would it then be better to just use existing information from related objects? I.e, if a power feed is "racked" then its table view and filter could use the tenant field from the rack itself.
I do not think it makes sense to duplicate this information.

@jsenecal commented on GitHub (Apr 14, 2023): Would it then be better to just use existing information from related objects? I.e, if a power feed is "racked" then its table view and filter could use the tenant field from the rack itself. I do not think it makes sense to duplicate this information.
adam commented 2025-12-29 20:29:32 +01:00
Author
Owner
Copy Link

@djmelik commented on GitHub (Apr 15, 2023):

I was thinking this over; what about in situations where a power feed does not belong to a rack -- for instance, standalone power circuits within cages or offices.

I think native tenancy or natively mapping tenants for all power objects is more extensible, offers greater scope and flexible, and is future proof for unaccounted use cases.

@djmelik commented on GitHub (Apr 15, 2023): I was thinking this over; what about in situations where a power feed does not belong to a rack -- for instance, standalone power circuits within cages or offices. I think native tenancy or natively mapping tenants for all power objects is more extensible, offers greater scope and flexible, and is future proof for unaccounted use cases.
adam commented 2025-12-29 20:29:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 4, 2023):

I can see the use case for power feeds, but power panels seems odd. I'm not necessarily opposed to it, I just find it difficult to envision a use case.

Going to mark this as needs milestone with the understanding that we'll at least add the assignment to power feeds.

@jeremystretch commented on GitHub (May 4, 2023): I can see the use case for power feeds, but power panels seems odd. I'm not necessarily _opposed_ to it, I just find it difficult to envision a use case. Going to mark this as `needs milestone` with the understanding that we'll at least add the assignment to power feeds.
adam commented 2025-12-29 20:29:33 +01:00
Author
Owner
Copy Link

@djmelik commented on GitHub (Sep 2, 2023):

Thanks guys! Looks great :)

@djmelik commented on GitHub (Sep 2, 2023): Thanks guys! Looks great :)
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 status: accepted 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#7883
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?