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

Implementation of "DeploymentTemplate" #1118

New Issue
Closed
opened 2025-12-29 16:29:09 +01:00 by adam · 8 comments
adam commented 2025-12-29 16:29:09 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (Jul 19, 2017).

Issue type:

Feature Request

Python version:
2.7.12
NetBox version:
2.0.10

There was a discussion today on the NetworkToCode Slack channel about the current limitations of interface_templates. The discussion began based off of the fact that in the current version of NetBox, you can create a parent LAG interface but not associate them with "built-in" physical interfaces.

@jeremystretch mentioned that his long-term goal was to (speaking about a Juniper EX4300) "have a library of devices defined in JSON with all their standard components so that you could just browse to juniper/switches/ex4300-48t.json in a repo and import the file and everyone could use that, because again, there's only one EX4300-48T."

I suggested a type of "template hierarchy" such that you could define "a standard EX4300 device_type to be created across the board, but then also allow some type of inheritance based of of what device_role is was initially created as."

The discussion continued with Jeremy coming up with the idea of something called a DeploymentTemplate which is "bound to a set of device_types and a set of device_roles and when you create a device matching both, arbitrary other things happen (like adding an ae0)."

This "issue" is just to have a record of that discussion and provide a forum to facilitate further comments on how it should be implemented along with any problems that may arise.

Originally created by @bdlamprecht on GitHub (Jul 19, 2017). ### Issue type: Feature Request **Python version:** 2.7.12 **NetBox version:** 2.0.10 There was a discussion today on the `NetworkToCode` Slack channel about the current limitations of `interface_templates`. The discussion began based off of the fact that in the current version of NetBox, you can create a parent `LAG` interface but not associate them with "built-in" physical interfaces. @jeremystretch mentioned that his long-term goal was to (speaking about a Juniper EX4300) "have a library of devices defined in JSON with all their standard components so that you could just browse to `juniper/switches/ex4300-48t.json` in a repo and import the file and everyone could use that, because again, there's only one EX4300-48T." I suggested a type of "template hierarchy" such that you could define "a standard EX4300 `device_type` to be created across the board, but then also allow some type of inheritance based of of what `device_role` is was initially created as." The discussion continued with Jeremy coming up with the idea of something called a `DeploymentTemplate` which is "bound to a set of `device_types` and a set of `device_roles` and when you create a device matching both, arbitrary other things happen (like adding an `ae0`)." This "issue" is just to have a record of that discussion and provide a forum to facilitate further comments on how it should be implemented along with any problems that may arise.
adam added the type: feature label 2025-12-29 16:29:09 +01:00
adam closed this issue 2025-12-29 16:29:09 +01:00
adam commented 2025-12-29 16:29:09 +01:00
Author
Owner
Copy Link

@SchwarzM commented on GitHub (Dec 5, 2017):

Hi,
as per MailingList I would like to add to this:

My device type has a strong correlation to the inventory of the device.
So instead of adding it to each and every instance of the device type,

I would like a central place where I can specify that each device of type x has 2 CPU's of type y.

Kind regards
Marian Schwarz

@SchwarzM commented on GitHub (Dec 5, 2017): Hi, as per MailingList I would like to add to this: My device type has a strong correlation to the inventory of the device. So instead of adding it to each and every instance of the device type, I would like a central place where I can specify that each device of type x has 2 CPU's of type y. Kind regards Marian Schwarz
adam commented 2025-12-29 16:29:10 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 26, 2018):

I know @jeremystretch is busy with getting v2.4 out of beta and ready for production, but any chance of this request making it into the v2.5 release?

@bdlamprecht commented on GitHub (Jul 26, 2018): I know @jeremystretch is busy with getting `v2.4` out of beta and ready for production, but any chance of this request making it into the `v2.5` release?
adam commented 2025-12-29 16:29:10 +01:00
Author
Owner
Copy Link

@FragmentedPacket commented on GitHub (Aug 28, 2018):

I would like to see this feature as well. I'd be willing to test this when it hits beta in whichever version is selected to release this feature.

@FragmentedPacket commented on GitHub (Aug 28, 2018): I would like to see this feature as well. I'd be willing to test this when it hits beta in whichever version is selected to release this feature.
adam commented 2025-12-29 16:29:10 +01:00
Author
Owner
Copy Link

@ngrundler commented on GitHub (Aug 28, 2018):

+1 here as well, I'm working on parsing my device configurations and loading them into Netbox, having this feature would be very welcome.

@ngrundler commented on GitHub (Aug 28, 2018): +1 here as well, I'm working on parsing my device configurations and loading them into Netbox, having this feature would be very welcome.
adam commented 2025-12-29 16:29:11 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 29, 2018):

Based off comments from @jeremystretch concerning what he is intending to target for v2.5, we might be lucky to see it in v2.6.

So unfortunately for us all, this feature is still quite a ways off.

@bdlamprecht commented on GitHub (Aug 29, 2018): Based off comments from `@jeremystretch` concerning what he is intending to target for `v2.5`, we _might_ be lucky to see it in `v2.6`. So unfortunately for us all, this feature is **still** quite a ways off.
adam commented 2025-12-29 16:29:11 +01:00
Author
Owner
Copy Link

@simora commented on GitHub (Sep 26, 2018):

+1

my support inspired by creating 600 devices and post-creation adding platform and LAG's (via the api ofcourse so its like complaining about cold ice cream).

deployment templates would allow operators to create devices and other objects in netbox with greater ease and with approved parameters pre-defined rather than hoping they can cobble everything together on their own.

@simora commented on GitHub (Sep 26, 2018): +1 my support inspired by creating 600 devices and post-creation adding platform and LAG's (via the api ofcourse so its like complaining about cold ice cream). deployment templates would allow operators to create devices and other objects in netbox with greater ease and with approved parameters pre-defined rather than hoping they can cobble everything together on their own.
adam commented 2025-12-29 16:29:11 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Mar 9, 2019):

Simply adding this from the NetworkToCode Slack for history purposes (referring to #1364):

I can see that according to GitHub, release v2.6 is slowly coming along.
Thanks for everyone who has contributed in making that happen as well as squashing the bugs that have popped up in the v2.5.x series.

I'm aware you can't give an exact timeframe for when FRs will be implemented, I'm merely asking if this is on the radar at all for v2.7

@bdlamprecht commented on GitHub (Mar 9, 2019): Simply adding this from the NetworkToCode Slack for history purposes (referring to #1364): >I can see that according to GitHub, release `v2.6` is slowly coming along. Thanks for everyone who has contributed in making that happen as well as squashing the bugs that have popped up in the `v2.5.x` series. >I'm aware you can't give an *exact* timeframe for when FRs will be implemented, I'm merely asking if this is on the radar at all for `v2.7`
adam commented 2025-12-29 16:29:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 29, 2021):

Looking back at this, it should be completely addressed by the addition of custom scripts. If anyone would like to re-propose it, please do so in a new feature request with a detailed use case relevant to NetBox v2.11 or later.

@jeremystretch commented on GitHub (Mar 29, 2021): Looking back at this, it should be completely addressed by the addition of custom scripts. If anyone would like to re-propose it, please do so in a new feature request with a detailed use case relevant to NetBox v2.11 or later.
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 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#1118
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?