Nasqueron uses NetBox as source of truth for its network. It’s mainly use for IPAM to store IP configuration, both for our private network and the public addresses.
NetBox allows to create custom fields to store extra information in addition to the base model.
We leveraged this to add default gateway, an information useful to configure network automatically through Salt. The only issue is the field was created for IPv4, with only one gateway, and we now need to store IPv6 gateway too.
You can’t do this migration through the UI. NetBox 3.4.8 disabled this possibility, #11431. And before, it created an error when trying to read the object the custom field is.
So migration plan is in three steps:
- Create a new field, with Multiple objects type.
- Copy the value from the other field to the new one, as a list of one element
- Delete the old field.
The first and third step can be done through the UI.
The migration can be automated through the API. If you want to use pynetbox, migrate-gateways.py gives you an example of how to proceed:
- iterate to all the objects containing your custom field –
.all()in pynetbox - populate the value of the new field with a list of one element:
[old field value] - save the object
For example, to migrate a custom field default_gw to default_gateways, field present in DCIM interfaces:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
def migrate_object(object, singleton_old_field, new_field): value = object.custom_fields[singleton_old_field] if value is not None: object.custom_fields[new_field] = [value] object.save() def run_migration(): nb = pynetbox.api(...) for interface in nb.dcim.interfaces.all(): migrate_object(interface, singleton_old_field, new_field) |
It’s pretty fast, and the changelog will show you the operation is smooth. Now you can delete the old field.
If NetBox gives you a 403 error, don’t forget tokens scope can be restricted. Try with an API token allowed to write.
If you need to cancel the operation, the easiest could be to backup the database before.