search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.77k stars 2.54k forks source link

seed data #176

Closed peelman closed 8 years ago

peelman commented 8 years ago

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

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.

ryanmerolle commented 8 years ago

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.

Gelob commented 8 years ago

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.

peelman commented 8 years ago

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.

jeremystretch commented 8 years ago

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.