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

Allow templating of virtual chassis position in templated component names on modules #7049

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

Originally created by @cpmills1975 on GitHub (Sep 29, 2022).

NetBox version

v3.3.4

Feature type

New functionality

Proposed functionality

When templating component names, e.g. interfaces, it is possible to include {module} in the name and have this replaced with the module position on instantiation. I'd like to propose expanding the selection of available templates to include the virtual chassis position.

Use case

Perhaps a bit of an edge case, but I was adding modules to a device that was already part of a virtual chassis. In the case of a JunOS or Cisco module, the interface names should would ideally be instantiated as interface-type/virtual chassis FPC number or FEX number/module slot/PIC number/interface number e.g. xe-1/2/3, Eth101/2/3, etc.

I was able to template the module/PIC number using the {module} tag, but not the FPC/FEX number. Had I been able to template the interface names as xe-{vcposition}/{module}/[0-7] or Eth{vcposition}/{module}/[1-8], I'd not have had to subsequently rename the interfaces that were instantiated.

Database changes

None

External dependencies

None

Originally created by @cpmills1975 on GitHub (Sep 29, 2022). ### NetBox version v3.3.4 ### Feature type New functionality ### Proposed functionality When templating component names, e.g. interfaces, it is possible to include {module} in the name and have this replaced with the module position on instantiation. I'd like to propose expanding the selection of available templates to include the virtual chassis position. ### Use case Perhaps a bit of an edge case, but I was adding modules to a device that was already part of a virtual chassis. In the case of a JunOS or Cisco module, the interface names should would ideally be instantiated as _interface-type_/_virtual chassis FPC number or FEX number_/_module slot/PIC number_/_interface number_ e.g. xe-1/2/3, Eth101/2/3, etc. I was able to template the module/PIC number using the {module} tag, but not the FPC/FEX number. Had I been able to template the interface names as xe-{vcposition}/{module}/[0-7] or Eth{vcposition}/{module}/[1-8], I'd not have had to subsequently rename the interfaces that were instantiated. ### Database changes None ### External dependencies None
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:48:20 +01:00
adam closed this issue 2025-12-29 19:48:20 +01:00
adam commented 2025-12-29 19:48:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 3, 2022):

Makes sense. We should be able to follow the same pattern we use for module position. I don't have a strong opinion the token name but vc_position might offer slightly better readability.

@jeremystretch commented on GitHub (Oct 3, 2022): Makes sense. We should be able to follow the same pattern we use for module position. I don't have a strong opinion the token name but `vc_position` might offer slightly better readability.
adam commented 2025-12-29 19:48:20 +01:00
Author
Owner
Copy Link

@cpund commented on GitHub (Oct 18, 2022):

I believe this is also related to #8648, which is something I'd also like to see implemented at one point. Still want to look at the code a bit before I commit to working on this myself. Would really like to see a better way to implement virtual chassis though. Having each member of a switch stack show as -0X in the device list gets a little wonky and less intuitive than just seeing the name of the stack itself.

@cpund commented on GitHub (Oct 18, 2022): I believe this is also related to #8648, which is something I'd also like to see implemented at one point. Still want to look at the code a bit before I commit to working on this myself. Would really like to see a better way to implement virtual chassis though. Having each member of a switch stack show as -0X in the device list gets a little wonky and less intuitive than just seeing the name of the stack itself.
adam commented 2025-12-29 19:48:20 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Oct 19, 2022):

It seems this is a duplicate of #8648 and some interesting points were raised by @jeremystretch at the time regarding devices and their components being instantiated before being added to a VC rather than at the same time. @DanSheps suggestion to offer the ability to template but with a default makes a lot of sense - in the case of Juniper ports, AFAIK the FPC number will always be zero unless the device is part of a VC so templating {vc_position:0} or something like that would be helpful here.

@cpmills1975 commented on GitHub (Oct 19, 2022): It seems this is a duplicate of #8648 and some interesting points were raised by @jeremystretch at the time regarding devices and their components being instantiated before being added to a VC rather than at the same time. @DanSheps suggestion to offer the ability to template but with a default makes a lot of sense - in the case of Juniper ports, AFAIK the FPC number will always be zero unless the device is part of a VC so templating `{vc_position:0}` or something like that would be helpful here.
adam commented 2025-12-29 19:48:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 19, 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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 19, 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:48:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 19, 2023):

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 (Jan 19, 2023): 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: needs owner 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#7049
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?