Closed bdlamprecht closed 5 years ago
To add some more context:
The issue we ran into is on the import, each custom field is sometimes (most of the time) mapped to the wrong netbox models. Best I can tell, this is due to ContentType
id's for models being unique to a django installation (assumption on my part).
I think there is value in this feature from a netbox development and testing standpoint. As more people start to use netbox in automation flows, the need to run dev/test instances of netbox will certainly increase and so will the need to ensure those environments are identical.
For inspiration how such a feature might work, and until such a feature is built-in to Netbox, you may find my little script for declaring and importing custom fields useful.
I don't usually write python code, so there might be a more elegant solution than this particular implementation, yet I think the concept is very intuitive.
I'd like to avoid exposing custom fields as objects in the front end (to preserve the demarcation between data and schema), but we can probably implement some form of import/export function in the admin UI.
Maybe this must not even be a feature in the UI but could be implemented through manage.py
?
Revisiting this. It seems like it's simple enough to do using Django's built-in dumpdata
and loaddata
management commands:
./manage.py dumpdata extras.customfield --indent 4 > customfields.json
./manage.py loaddata customfields.json
The content type IDs referenced by obj_type
might need to be updated by hand if importing to a different NetBox instance, but I think that's a reasonable limitation given how infrequently it's likely to be used. Anything more involved is probably going to require some degree of custom scripting anyway.
Issue type
[X] Feature request [ ] Bug report [ ] Documentation
Environment
Description
Currently, I'm working on migrating from a development instance of NetBox to a production instance and would like to move a number of
custom_fields
that I've created specific to this customer between these two instances. While I could manually create them by hand and at present would not be too much of a problem to do, once this goes live into production, I expect a lot of other needs are going to pop up requiring additionalcustom_fields
which I'll have to test against in the my development instance. Also, inconsistencies may occur due to the "human element", so that is, in my opinion, a non-starter.@lampwins helped kind of helped me do it with a
pg_dump
command and they were imported without any errors being reported, however, when I did this, thecustom_fields
were mapped to the incorrectmodels
and I had to go into the Admin site and re-map them.How difficult do you think this functionality would be to implement?