Closed sol1-matt closed 3 weeks ago
@sol1-matt I agree with your definition of infrastructure data and also that we should avoid DB dumps.
We should use a script that both talks to the API and is idempotent. This is not difficult (Ansible and diffsync are both options we have available to us), I'll just need the list we need for our initial state. We probably need a holistic view here as the Slurpit onboarding instructions already expected a site called Denver
to be present which we can re-use and Slurpit can already create Device Types for us.
Maybe the best place to start is defining what Icinga2 will expect to see in NetBox and working back from there. That probably depends on what we would like to monitor. A call might be best.
If we are going the script route that is idempotent (which I'm happy with) then I don't think it matters what data we need now.
I'd be inclined to put the something in place that calls the script at the end of the start up process and then reads a set of things we need
the set of things we need could be as simple as object type plus key value pairs
I know some of the data I need now, but as things are setup I'm expecting to need add things later so I guess I'm thinking of making that process as easy as possible.
I agree that we should use a script to set everything up once the installation is done so that the users have as little as possible to do. I'm actually already doing some of that for Netpicker here (not idempotent yet):
https://github.com/mrmrcoleman/autocon2_workshop/blob/main/workshop_setup/netpicker/setup.py
That is called from the installation script, which is the model we should aim for: https://github.com/mrmrcoleman/autocon2_workshop/blob/main/6_start_netpicker.sh
Needs to be tested but this is seems like a decent starting point for getting infrastructure data in Netbox in a idempotent way https://github.com/sol1-matt/autocon2_workshop/tree/main/workshop_setup/netbox
This approach works. Closing.
Infrastructure data for Netbox is any data relied on by other things and need to be created before other part of the demo can run.
This could be things like Device Roles, Contacts, Sites, Tenants, Tags, Custom Fields, etc...
Perhaps imports or scripts that write to the api can be run and easily updated so we can update them as we develop things. I dump of the DB to be restore would also work but may be harder to update as we test things.
Thoughts @mrmrcoleman