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

Have v3.0.0+ migration command check for pre-2.11 db state and raise explicit error about that #5302

New Issue
Closed
opened 2025-12-29 19:26:26 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:26:26 +01:00
Owner
Copy Link

Originally created by @mk-fg on GitHub (Sep 2, 2021).

NetBox version

v3.0.0

Feature type

Change to existing functionality

Proposed functionality

Hi,

I've been asked to check if NetBox container migrates to 3.0.0 without issues and got long and somewhat cryptic traceback like mentioned here: https://github.com/netbox-community/netbox-docker/issues/562

It was also hidden by docker container entrypoint, which was what the issue was about, not the error/traceback itself, but almost immediately another person jumped in and asked what to do about that error/traceback, indicating that I wasn't the only person briefly confused by it on update.

Granted, Release Notes clearly mention this issue on the very first line, but in reality, of course no one reads these until after the update in the very best-case scenario.

So I thought to suggest adding a small check to django migrations that'd see if current migration-state recorded in db is earlier than 2.11 and raise some clear error like "Please update NetBox to 2.11 first, see 3.0.0 Release Notes for more info." instead of that thing in the linked issue above.

Use case

Obviously this is not very relevant for me, but though to propose this anyway, in case this was not considered already, as it seem to be a no-brainer improvement, and apparently relevant one.
And maybe relevant for a while too, as I'm sure people who update from <2.10 are statistically more likely to update less often (as is demonstrated by their old NetBox version), and can be updating it a year or two from now.

Benefit is a long-term externality to avoid reinforcing the notion that software updates always break things in a cryptic way, generally not supported by the developers in practice, and should only be done as a last resort, probably after some terrible compromise or other disaster, if ever.

Thanks!

Database changes

No response

External dependencies

No response

Originally created by @mk-fg on GitHub (Sep 2, 2021). ### NetBox version v3.0.0 ### Feature type Change to existing functionality ### Proposed functionality Hi, I've been asked to check if NetBox container migrates to 3.0.0 without issues and got long and somewhat cryptic traceback like mentioned here: https://github.com/netbox-community/netbox-docker/issues/562 It was also hidden by docker container entrypoint, which was what the issue was about, not the error/traceback itself, but almost immediately another person jumped in and asked what to do about that error/traceback, indicating that I wasn't the only person briefly confused by it on update. Granted, Release Notes clearly mention this issue on the very first line, but in reality, of course no one reads these until after the update in the very best-case scenario. So I thought to suggest adding a small check to django migrations that'd see if current migration-state recorded in db is earlier than 2.11 and raise some clear error like "Please update NetBox to 2.11 first, see 3.0.0 Release Notes for more info." instead of that thing in the linked issue above. ### Use case Obviously this is not very relevant for me, but though to propose this anyway, in case this was not considered already, as it seem to be a no-brainer improvement, and apparently relevant one. And maybe relevant for a while too, as I'm sure people who update from <2.10 are statistically more likely to update less often (as is demonstrated by their old NetBox version), and can be updating it a year or two from now. Benefit is a long-term externality to avoid reinforcing the notion that software updates always break things in a cryptic way, generally not supported by the developers in practice, and should only be done as a last resort, probably after some terrible compromise or other disaster, if ever. Thanks! ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:26:26 +01:00
adam closed this issue 2025-12-29 19:26:26 +01:00
adam commented 2025-12-29 19:26:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

Granted, Release Notes clearly mention this issue on the very first line, but in reality, of course no one reads these until after the update in the very best-case scenario.

I don't agree with this assertion. Many people, if not most, do in fact read the release notes to understand the impact of the change they're about to make. Those who opt not to are making an irresponsible and dangerous decision to incur additional risk without reason.

So I thought to suggest adding a small check to django migrations that'd see if current migration-state recorded in db is earlier than 2.11

This is something we looked into while working on v3.0, but didn't find any solution that could be reliably implemented given that we have to support releases that were already in the wild. The only way I found to infer migration status after the code base had been staged for v3.0 was via the showmigrations management command, which would have been very hacky to employ.

I'm open to suggestion if anyone has a feasible idea for the actual implementation, but otherwise we won't spend any more time on it as it's clearly called out in the release notes already.

@jeremystretch commented on GitHub (Sep 2, 2021): > Granted, Release Notes clearly mention this issue on the very first line, but in reality, of course no one reads these until after the update in the very best-case scenario. I don't agree with this assertion. Many people, if not most, do in fact read the release notes to understand the impact of the change they're about to make. Those who opt not to are making an irresponsible and dangerous decision to incur additional risk without reason. > So I thought to suggest adding a small check to django migrations that'd see if current migration-state recorded in db is earlier than 2.11 This is something we looked into while working on v3.0, but didn't find any solution that could be reliably implemented given that we have to support releases that were already in the wild. The only way I found to infer migration status _after_ the code base had been staged for v3.0 was via the `showmigrations` management command, which would have been very hacky to employ. I'm open to suggestion if anyone has a feasible idea for the actual implementation, but otherwise we won't spend any more time on it as it's clearly called out in the release notes already.
adam commented 2025-12-29 19:26:27 +01:00
Author
Owner
Copy Link

@mk-fg commented on GitHub (Sep 2, 2021):

I don't agree with this assertion. Many people, if not most, do in fact read the release notes to understand the impact of the change they're about to make.

Ah, fair enough, don't have any hard data on it myself, though didn't really think it'd be controversial, but maybe that's just my experience and biases.

This is something we looked into while working on v3.0, but didn't find any solution that could be reliably implemented given that we have to support releases that were already in the wild.

Unfortunate.
Thought it might be possible and maybe even straightforward, given all the signal hook-points that django has all over the place and that it allows raw sql queries through its ORM.

Putting such message into showmigrations would actually help with that docker container, as entrypoint script runs it to check db connection, but guess you considered this already and it's not worth it.
Don't think I have good enough grasp on django to suggest anything useful, and definitely not if you've already looked for a solution there and haven't found an acceptable one.

Thanks for clearing it up, and apologies for the noise.

@mk-fg commented on GitHub (Sep 2, 2021): > I don't agree with this assertion. Many people, if not most, do in fact read the release notes to understand the impact of the change they're about to make. Ah, fair enough, don't have any hard data on it myself, though didn't really think it'd be controversial, but maybe that's just my experience and biases. > This is something we looked into while working on v3.0, but didn't find any solution that could be reliably implemented given that we have to support releases that were already in the wild. Unfortunate. Thought it might be possible and maybe even straightforward, given all the signal hook-points that django has all over the place and that it allows raw sql queries through its ORM. Putting such message into showmigrations would actually help with that docker container, as entrypoint script runs it to check db connection, but guess you considered this already and it's not worth it. Don't think I have good enough grasp on django to suggest anything useful, and definitely not if you've already looked for a solution there and haven't found an acceptable one. Thanks for clearing it up, and apologies for the noise.
adam commented 2025-12-29 19:26:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 3, 2021):

Going to close this out as there's no action to be taken at this time. If anyone would like to propose a specific implementation to address this concern, we'll happily evaluate it.

@jeremystretch commented on GitHub (Sep 3, 2021): Going to close this out as there's no action to be taken at this time. If anyone would like to propose a specific implementation to address this concern, we'll happily evaluate it.
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: feature
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#5302
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?