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

seed data #138

New Issue
Closed
opened 2025-12-29 15:34:48 +01:00 by adam · 4 comments
adam commented 2025-12-29 15:34:48 +01:00
Owner
Copy Link

Originally created by @peelman on GitHub (Jul 1, 2016).

From a first-install stand point, there really should be some seed data added. For starters:

  • RIRs (the five big, plus RFC1918/6598).
  • RFC1918 Aggregates (keeping in mind the user is free to delete whatever they want)
  • Generic Prefix/VLAN Roles
  • Generic Device Roles
  • Generic Circuit Types
  • Common Platforms (JunOS, IOS, NX-OS, etc)

Please add more or debate as you see fit...I assume this was already a Todo somewhere, but I couldn't find reference to it in an existing issue.

Originally created by @peelman on GitHub (Jul 1, 2016). From a first-install stand point, there really should be some seed data added. For starters: - RIRs (the five big, plus RFC1918/6598). - RFC1918 Aggregates (keeping in mind the user is free to delete whatever they want) - Generic Prefix/VLAN Roles - Generic Device Roles - Generic Circuit Types - Common Platforms (JunOS, IOS, NX-OS, etc) Please add more or debate as you see fit...I assume this was already a Todo somewhere, but I couldn't find reference to it in an existing issue.
adam added the type: feature label 2025-12-29 15:34:48 +01:00
adam closed this issue 2025-12-29 15:34:48 +01:00
adam commented 2025-12-29 15:34:50 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 1, 2016):

Mentioned it #148, but I did not list out as clearly as your issue. I also went into some discussion on an updated demo site for group testing. It probably makes sense to close out my issue given the demo is hosted on Stretch's blog and your issue better illustrates the seed data types required.

@ryanmerolle commented on GitHub (Jul 1, 2016): Mentioned it #148, but I did not list out as clearly as your issue. I also went into some discussion on an updated demo site for group testing. It probably makes sense to close out my issue given the demo is hosted on Stretch's blog and your issue better illustrates the seed data types required.
adam commented 2025-12-29 15:34:51 +01:00
Author
Owner
Copy Link

@Gelob commented on GitHub (Jul 3, 2016):

Some of the idea discussion about this on IRC was that we could have a separate community maintained repo with that information and users could pull it down via a simple JSON import or such into netbox.

@Gelob commented on GitHub (Jul 3, 2016): Some of the idea discussion about this on IRC was that we could have a separate community maintained repo with that information and users could pull it down via a simple JSON import or such into netbox.
adam commented 2025-12-29 15:34:51 +01:00
Author
Owner
Copy Link

@peelman commented on GitHub (Jul 5, 2016):

So instead of either an automatic step or an elected additional step during during deployment, the admin would need to do a series of imports (either at the command line or in the web interface) to load the seed data? Yuk.

Especially for things like the default RIRs, I'd argue that should be baked in as part of the initial migration. Those are going to be very static in terms of seed data. Same goes for the RFC1918 aggregates. Again, if the admin elects to remove them for simplicity or their own eccentricities, super, that's why its just seed data and not hard coded.

From a usability standpoint, out-of-the-netbox NetBox isn't usable because you have to spend 30 minutes figuring out where you need to add a bunch of dependencies before you can start adding infrastructure bits. I get that we are all UNIX nerds, but lets not make life more difficult than it needs to be, just because we are used to it.

@peelman commented on GitHub (Jul 5, 2016): So instead of either an automatic step or an elected additional step during during deployment, the admin would need to do a series of imports (either at the command line or in the web interface) to load the seed data? Yuk. Especially for things like the default RIRs, I'd argue that should be baked in as part of the initial migration. Those are going to be very static in terms of seed data. Same goes for the RFC1918 aggregates. Again, if the admin elects to remove them for simplicity or their own eccentricities, super, that's why its just seed data and not hard coded. From a usability standpoint, out-of-the-netbox NetBox isn't usable because you have to spend 30 minutes figuring out where you need to add a bunch of dependencies before you can start adding infrastructure bits. I get that we are all UNIX nerds, but lets not make life more difficult than it needs to be, just because we are used to it.
adam commented 2025-12-29 15:34:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 9, 2016):

I think the JSON piece @Gelob referred to might have been my remark about starting an external library to hold DeviceType definitions, from which a user could import only the ones they care about. This would be totally separate from any seed data for initial installs (unless I'm misunderstanding).

I'd love to have some seed data. FYI Django calls these "fixtures" and they can be defined in either JSON or YAML.

@jeremystretch commented on GitHub (Jul 9, 2016): I think the JSON piece @Gelob referred to might have been my remark about starting an external library to hold DeviceType definitions, from which a user could import only the ones they care about. This would be totally separate from any seed data for initial installs (unless I'm misunderstanding). I'd love to have some seed data. FYI Django calls these "fixtures" and they can be defined in either [JSON or YAML](https://docs.djangoproject.com/en/1.9/howto/initial-data/).
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#138
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?