starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Config Revisions return at the first occurrence when Netbox restarts #9310

New Issue
Closed
opened 2025-12-29 20:48:15 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:48:15 +01:00
Owner
Copy Link

Originally created by @chrisho95 on GitHub (Feb 29, 2024).

Deployment Type

Self-hosted

NetBox Version

v3.7.3

Python Version

3.11

Steps to Reproduce

  1. Create two Configuration revisons in Admin -> CONFIGURATION -> Config Revisions
    The second config is Active

image

  1. Restart Netbox
    The first confg is Active and the second config is Inactive

image

  1. I have to reactivate the latest version

image

Expected Behavior

When netbox restarts, I would like the last config to remain active.

Observed Behavior

It happened that the first config was activated when restarting Netbox and the second was deactivated.

Originally created by @chrisho95 on GitHub (Feb 29, 2024). ### Deployment Type Self-hosted ### NetBox Version v3.7.3 ### Python Version 3.11 ### Steps to Reproduce 1. Create two Configuration revisons in Admin -> CONFIGURATION -> Config Revisions The second config is Active ![image](https://github.com/netbox-community/netbox/assets/82440344/0abbb73f-c382-4303-b77f-a60fa5bd62dd) 2. Restart Netbox The first confg is Active and the second config is Inactive ![image](https://github.com/netbox-community/netbox/assets/82440344/e068cd2d-8174-40f8-a4c4-cee0b2496489) 3. I have to reactivate the latest version ![image](https://github.com/netbox-community/netbox/assets/82440344/390dcaa5-c12d-4a24-aca9-c75de039f136) ### Expected Behavior When netbox restarts, I would like the last config to remain active. ### Observed Behavior It happened that the first config was activated when restarting Netbox and the second was deactivated.
adam added the type: bug label 2025-12-29 20:48:15 +01:00
adam closed this issue 2025-12-29 20:48:15 +01:00
adam commented 2025-12-29 20:48:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 29, 2024):

I'm unable to reproduce this behavior.

  1. Restart Netbox

What exactly are you restarting? The current configuration version is stored in Redis, so if you're destroying the Redis database somehow then yes you'll lose the active configuration (along with any other cached data or queued jobs).

@jeremystretch commented on GitHub (Feb 29, 2024): I'm unable to reproduce this behavior. > 2. Restart Netbox What exactly are you restarting? The current configuration version is stored in Redis, so if you're destroying the Redis database somehow then yes you'll lose the active configuration (along with any other cached data or queued jobs).
adam commented 2025-12-29 20:48:16 +01:00
Author
Owner
Copy Link

@chrisho95 commented on GitHub (Mar 1, 2024):

I forgot to mention that my netbox instance was installed on docker.

So to restart Netbox I do "docker-compose down && docker-compose up -d".

On older versions of Netbox I didn't have this problem.

@chrisho95 commented on GitHub (Mar 1, 2024): I forgot to mention that my netbox instance was installed on docker. So to restart Netbox I do "docker-compose down && docker-compose up -d". On older versions of Netbox I didn't have this problem.
adam commented 2025-12-29 20:48:17 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Mar 1, 2024):

Do you have a persistent volume attached to your redis instance? It seems to me that your redis is losing the applied revision

@abhi1693 commented on GitHub (Mar 1, 2024): Do you have a persistent volume attached to your redis instance? It seems to me that your redis is losing the applied revision
adam commented 2025-12-29 20:48:17 +01:00
Author
Owner
Copy Link

@chrisho95 commented on GitHub (Mar 1, 2024):

Yes.

# redis
redis-reseau:
image: redis:7-alpine
container_name: redis-reseau
restart: unless-stopped
command:
- sh
- -c # this is to evaluate the $REDIS_PASSWORD from the env
- redis-server --appendonly yes --requirepass FOOBAR
env_file: ./env/redis.env
volumes:
- netbox-redis-data:/data

@chrisho95 commented on GitHub (Mar 1, 2024): Yes. **# redis redis-reseau: image: redis:7-alpine container_name: redis-reseau restart: unless-stopped command: - sh - -c # this is to evaluate the $REDIS_PASSWORD from the env - redis-server --appendonly yes --requirepass FOOBAR env_file: ./env/redis.env volumes: - netbox-redis-data:/data**
adam commented 2025-12-29 20:48:17 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Mar 4, 2024):

netbox-redis-data

Make this a bind mount or an external volume. It should then survive the destruction of the docker-compose project.

@jsenecal commented on GitHub (Mar 4, 2024): > netbox-redis-data Make this a bind mount or an external volume. It should then survive the destruction of the docker-compose project.
adam commented 2025-12-29 20:48:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 8, 2024):

From the discussion above this appears to be related to the specific means of deployment and not something that can be addressed in NetBox itself. If means to reproduce this in NetBox natively can be identified, I'll be happy to reopen this issue.

@jeremystretch commented on GitHub (Mar 8, 2024): From the discussion above this appears to be related to the specific means of deployment and not something that can be addressed in NetBox itself. If means to reproduce this in NetBox natively can be identified, I'll be happy to reopen this issue.
adam commented 2025-12-29 20:48:17 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (May 2, 2024):

We also run docker, and have done so for years without issues. We have upgraded out test/integrationtest and production environments from 3.4.10 to 3.7.5 the past three weeks. All of the environments behave in the same way! And we use persistent volumes, in this case also on different disks systems. It always default back to the first config revision after an restart of Netbox.

Now, as I understand it, Redis is involved here, but in what way? How is the configuration revision stored and read by Netbox when starting up?

@ziggekatten commented on GitHub (May 2, 2024): We also run docker, and have done so for years without issues. We have upgraded out test/integrationtest and production environments from 3.4.10 to 3.7.5 the past three weeks. All of the environments behave in the same way! And we use persistent volumes, in this case also on different disks systems. It always default back to the first config revision after an restart of Netbox. Now, as I understand it, Redis is involved here, but in what way? How is the configuration revision stored and read by Netbox when starting up?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9310
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?