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 context on 'Tag' does not appear on tagged VMs #3563

New Issue
Closed
opened 2025-12-29 18:29:53 +01:00 by adam · 11 comments
adam commented 2025-12-29 18:29:53 +01:00
Owner
Copy Link

Originally created by @cpmills1975 on GitHub (Apr 14, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.7.7
  • NetBox version: 2.8.0

Steps to Reproduce

  1. Create a device with a tag 'tag1'
  2. Create a VM with a tag 'tag1'
  3. Create a config context that applies to tag 'tag1'
  4. Examine the rendered config context for the device
  5. Examine the rendered config context for the VM

Expected Behavior

The same rendered config context should appear in both the device and the VM.

Observed Behavior

The config context appears only for the device and not the VM

Originally created by @cpmills1975 on GitHub (Apr 14, 2020). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.7.7 * NetBox version: 2.8.0 ### Steps to Reproduce 1. Create a device with a tag 'tag1' 2. Create a VM with a tag 'tag1' 3. Create a config context that applies to tag 'tag1' 4. Examine the rendered config context for the device 5. Examine the rendered config context for the VM <!-- What did you expect to happen? --> ### Expected Behavior The same rendered config context should appear in both the device and the VM. <!-- What happened instead? --> ### Observed Behavior The config context appears only for the device and not the VM
adam added the type: bug label 2025-12-29 18:29:53 +01:00
adam closed this issue 2025-12-29 18:29:53 +01:00
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2020):

I'm not able to replicate this on v2.8.0. The config context is applied to both the device and the VM. Both models use the same underlying view (ObjectConfigContextView) to render the config context.

@jeremystretch commented on GitHub (Apr 14, 2020): I'm not able to replicate this on v2.8.0. The config context is applied to both the device and the VM. Both models use the same underlying view (ObjectConfigContextView) to render the config context.
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Apr 14, 2020):

Could it be a caching issue? I've just created a new VM named 'A', added the tag (during creation) and the config context does appear. Now, if I edit that VM and remove the tag, the config context doesn't immediately disappear. If I clone it to a VM called 'B', that DOESN'T show the config context (expected). Editing 'B' to add the tag, also doesn't show the config context but if I clone it again to a VM called 'C' (c HAS the tag) the config context is visible on C.

A simpler way to demonstrate this is to create two VMs, one with and one without the tag on creation, then add the tag to the one that doesn't have it. The config context remains visible only on the device that had the tag on creation.

Does Django/Netbox cache the rendered objects internally? What I am seeing in the web interface is reflected in the API too (tag1 has an applicable config context defined):

{
<snip>
  "tags": [
    "tag1"
  ],
  "custom_fields": {},
  "config_context": {}.
<snip>
}

FWIW, I am running a dev instance of NetBox using netbox-docker. My prod instance is older and running as a dedicated install (without docker atm).

@cpmills1975 commented on GitHub (Apr 14, 2020): Could it be a caching issue? I've just created a new VM named 'A', added the tag (during creation) and the config context does appear. Now, if I edit that VM and remove the tag, the config context doesn't immediately disappear. If I clone it to a VM called 'B', that DOESN'T show the config context (expected). Editing 'B' to add the tag, also doesn't show the config context but if I clone it again to a VM called 'C' (c HAS the tag) the config context is visible on C. A simpler way to demonstrate this is to create two VMs, one with and one without the tag on creation, then add the tag to the one that doesn't have it. The config context remains visible only on the device that had the tag on creation. Does Django/Netbox cache the rendered objects internally? What I am seeing in the web interface is reflected in the API too (tag1 has an applicable config context defined): ``` { <snip> "tags": [ "tag1" ], "custom_fields": {}, "config_context": {}. <snip> } ``` FWIW, I am running a dev instance of NetBox using netbox-docker. My prod instance is older and running as a dedicated install (without docker atm).
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2020):

Could it be a caching issue?

Can you reproduce it with caching disabled?

@jeremystretch commented on GitHub (Apr 14, 2020): > Could it be a caching issue? Can you reproduce it with caching disabled?
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Apr 14, 2020):

Sorry, how do I disable caching? I'm assuming it is not browser end caching due to it being reflected in the API output and I've gone in to the developer view to make sure the web requests are getting proper status 200 responses.

@cpmills1975 commented on GitHub (Apr 14, 2020): Sorry, how do I disable caching? I'm assuming it is not browser end caching due to it being reflected in the API output and I've gone in to the developer view to make sure the web requests are getting proper status 200 responses.
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2020):

Set CACHE_TIMEOUT = 0 in configuration.py, then restart the NetBox service.

@jeremystretch commented on GitHub (Apr 14, 2020): Set `CACHE_TIMEOUT = 0` in configuration.py, then restart the NetBox service.
adam commented 2025-12-29 18:29:54 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Apr 14, 2020):

Yep. That's it. I actually noticed (at least I thought I did - now confirmed), that the config context corrected itself around the same time as the VM said 'Updated 15 minutes ago'. I can see the default cache timeout is 900 seconds which is either entirely coincidental or Django was indeed caching the VM for 15 minutes. Disabling the caching has 'fixed' my problem. I'll happily close this issue.

Many thanks.

@cpmills1975 commented on GitHub (Apr 14, 2020): Yep. That's it. I actually noticed (at least I thought I did - now confirmed), that the config context corrected itself around the same time as the VM said 'Updated 15 minutes ago'. I can see the default cache timeout is 900 seconds which is either entirely coincidental or Django was indeed caching the VM for 15 minutes. Disabling the caching has 'fixed' my problem. I'll happily close this issue. Many thanks.
adam commented 2025-12-29 18:29:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2020):

I'm glad this is a suitable workaround for you, however we (the maintainers) still need to address the root issue, so I'm going to re-open this.

@jeremystretch commented on GitHub (Apr 14, 2020): I'm glad this is a suitable workaround for you, however we (the maintainers) still need to address the root issue, so I'm going to re-open this.
adam commented 2025-12-29 18:29:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 15, 2020):

I played around with this for a bit but have not been able to replicate it with caching enabled. Updating a config context or creating a new one always results in a new query being issued by the next request for a device/VM.

@cpmills1975 can you take another look at the exact steps needed to reproduce on v2.8?

@jeremystretch commented on GitHub (Apr 15, 2020): I played around with this for a bit but have not been able to replicate it with caching enabled. Updating a config context or creating a new one always results in a new query being issued by the next request for a device/VM. @cpmills1975 can you take another look at the exact steps needed to reproduce on v2.8?
adam commented 2025-12-29 18:29:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 21, 2020):

I'm going to close this out as I have been unable to reproduce it on v2.8, but please comment here if you are able to and I'll re-open it.

@jeremystretch commented on GitHub (Apr 21, 2020): I'm going to close this out as I have been unable to reproduce it on v2.8, but please comment here if you are able to and I'll re-open it.
adam commented 2025-12-29 18:29:55 +01:00
Author
Owner
Copy Link

@1977er commented on GitHub (Sep 3, 2020):

I can reproduce this on a Netbox v2.8.9.
Tagged VMs/devices do not get the config context assigned until I make an (empty) update on the ConfigContext object. When I set CACHE_TIMEOUT = 0 the config contexts get assigned immediately (without edit-save cycle on the CC object).

Sorry, cannot test on 2.9 yet.

@1977er commented on GitHub (Sep 3, 2020): I can reproduce this on a Netbox v2.8.9. Tagged VMs/devices do not get the config context assigned until I make an (empty) update on the ConfigContext object. When I set `CACHE_TIMEOUT = 0` the config contexts get assigned immediately (without edit-save cycle on the CC object). Sorry, cannot test on 2.9 yet.
adam commented 2025-12-29 18:29:55 +01:00
Author
Owner
Copy Link

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

The v2.8 train is no longer being developed. Only bugs on a recent v2.9 release will be addressed.

@jeremystretch commented on GitHub (Sep 3, 2020): The v2.8 train is no longer being developed. Only bugs on a recent v2.9 release will be addressed.
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#3563
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?