The oldest config revision is activated when replicating NetBox #861

New Issue

MrUnknownDE · 2026-04-05T18:15:10+02:00

MrUnknownDE commented

2026-04-05 18:15:10 +02:00

Originally created by @markkuleinio on 11/18/2025

NetBox Edition

NetBox Community

NetBox Version

v4.4.6

Python Version

3.11

Steps to Reproduce

Install new NetBox 4.3.7 ** (git checkout v4.3.7) server as per official instructions but don't run upgrade.sh yet
pg_dump a NetBox 3.7.3 database from an existing NetBox server and import it on the new server
Run upgrade.sh
See that the core_configrevision table does not yet have active column
git checkout v4.4.6 and run upgrade.sh
See that there is a new active column in the core_configrevision table
See that the oldest configrevision has active = true

(** In some experiences, including my own, it is not possible to upgrade a NetBox 3.7.3 database directly to 4.4.x, thus the intermediate upgrade step via 4.3.7.)

Expected Behavior

The newest configuration revision is active when NetBox database is replicated from old version to new version.

Observed Behavior

The oldest configuration revision is active.

This is a major problem because the NetBox background task starts immediately (after starting the new NetBox services) deleting old changelog entries according to the retention time configured in the active config revision. Thus, if/when the oldest config revision has retention time shorter than the latest config revision, old changelogs are unintentionally lost.

Workaround attempt: I set the newest config revision as active=true (required also setting the oldest revision to active=false before that) in the database before starting NetBox services the first time. While it looks like the newest config revision is now active in the UI, the background task still executed the cleanup task with the old settings:

2025-11-18 15:27:48,165 netbox.jobs.SystemHousekeepingJob INFO: Pruning old changelog entries...
2025-11-18 15:27:48,168 netbox.jobs.SystemHousekeepingJob DEBUG: Changelog retention period: 1825 days (2020-11-19 13:27:48)
2025-11-18 15:27:50,020 netbox.jobs.SystemHousekeepingJob INFO: Deleted 221 expired changelog records

(1825 days was set in the oldest config revision, while the newest (now active) revision has 0)

While testing this workaround I observed that some data in Redis also affected this: When I had manually activated the latest config revision in the UI and then deleted, imported and upgraded the database again, the problem did not occur, meaning that the latest config revision was still active (INFO: Pruning old changelog entries..., INFO: No retention period specified; skipping.). But, when I also reinstalled redis-server (when importing the database again), the error occurred. Thus, apparently in-place upgrades work correctly, but not migrations/replications to new servers. Maybe this would be a useful workaround as well: https://stackoverflow.com/questions/6004915/how-do-i-move-a-redis-database-from-one-server-to-another .

Or maybe the workaround currently is to first execute the migration+upgrade steps and activate the latest revision (which deleted unintended changelogs), and then do the steps again on the same server so that the data in Redis database takes care of not using the oldest revision at all.

Another workaround is probably removing all config revisions but the latest one (to prevent the cleanup job runaway with incorrect settings), but that's not ideal as all the config revision history is then lost in the UI.

*Originally created by @markkuleinio on 11/18/2025* ### NetBox Edition NetBox Community ### NetBox Version v4.4.6 ### Python Version 3.11 ### Steps to Reproduce 1. Install new NetBox 4.3.7 ** (`git checkout v4.3.7`) server as per official instructions but don't run `upgrade.sh` yet 2. `pg_dump` a NetBox 3.7.3 database from an existing NetBox server and import it on the new server 3. Run `upgrade.sh` 4. See that the `core_configrevision` table does not yet have `active` column 5. `git checkout v4.4.6` and run `upgrade.sh` 6. See that there is a new `active` column in the `core_configrevision` table 7. See that the **oldest** configrevision has `active = true` (** In [some experiences, including my own](https://github.com/netbox-community/netbox/discussions/20582), it is not possible to upgrade a NetBox 3.7.3 database directly to 4.4.x, thus the intermediate upgrade step via 4.3.7.) ### Expected Behavior The **newest** configuration revision is active when NetBox database is replicated from old version to new version. ### Observed Behavior The **oldest** configuration revision is active. This is a major problem because the NetBox background task starts _immediately_ (after starting the new NetBox services) deleting old changelog entries according to the retention time configured in the active config revision. Thus, if/when the oldest config revision has retention time shorter than the latest config revision, old changelogs are unintentionally lost. **Workaround attempt:** I set the newest config revision as `active=true` (required also setting the oldest revision to `active=false` before that) in the database before starting NetBox services the first time. While it looks like the newest config revision is now active in the UI, **the background task still executed the cleanup task with the old settings**: ``` 2025-11-18 15:27:48,165 netbox.jobs.SystemHousekeepingJob INFO: Pruning old changelog entries... 2025-11-18 15:27:48,168 netbox.jobs.SystemHousekeepingJob DEBUG: Changelog retention period: 1825 days (2020-11-19 13:27:48) 2025-11-18 15:27:50,020 netbox.jobs.SystemHousekeepingJob INFO: Deleted 221 expired changelog records ``` (1825 days was set in the oldest config revision, while the newest (now active) revision has 0) While testing this workaround I observed that some data in **Redis** also affected this: When I had manually activated the latest config revision in the UI and then deleted, imported and upgraded the database **again**, the problem did not occur, meaning that the latest config revision was still active (`INFO: Pruning old changelog entries...`, `INFO: No retention period specified; skipping.`). But, when I also reinstalled `redis-server` (when importing the database again), the error occurred. Thus, apparently in-place upgrades work correctly, but not migrations/replications to new servers. Maybe this would be a useful workaround as well: https://stackoverflow.com/questions/6004915/how-do-i-move-a-redis-database-from-one-server-to-another . Or maybe the workaround currently is to first execute the migration+upgrade steps and activate the latest revision (which deleted unintended changelogs), and then do the steps again on the same server so that the data in Redis database takes care of **not** using the oldest revision at all. Another workaround is probably removing all config revisions but the latest one (to prevent the cleanup job runaway with incorrect settings), but that's not ideal as all the config revision history is then lost in the UI.

MrUnknownDE closed this issue

2026-04-05 18:15:10 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium severity: medium status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#861