Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config Context for hardware devices interferes with virtual machines in confusing way #7674

Closed
mburggraf opened this issue Oct 28, 2021 · 0 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@mburggraf
Copy link

NetBox version

v3.0.8

Python version

3.8

Steps to Reproduce

The following issue was completely reproduced in the netbox test environment (https://demo.netbox.dev/).

  1. Create a config context with some settings and assign it to any Site.
    For example: { "category": { "value 1": 10, "value 2": 20 } }
  2. Look for a virtual machine, with a cluster matching the assigned Site and verify, that the config context gets correctly applied.
  3. Create an additional config context, with overlapping contents and apply it to any device type only.
    For example: { "category": { "value 2": 200, "value 3": 300, "value 4": 400 } }
  4. Go back to the virtual machine you checked before and see, how the Rendered config context shows data which doesn't match the source contents.

Expected Behavior

The rendered config context should only contain the combined source contents, which match the given context. Especially a context, which is set to apply to a specific device type only should never appear in a virtual machine.

Observed Behavior

Values from the device type config context gets mixed into the rendered context, without even appearing in source context, and without matching:
grafik


There is an additional thing; I don't know if it is the same Bug, or another issue.

What happens: The export, which is called without /api/ shows the values how they should be. When calling it via the /api/-Link, the same problem happens as above.
I would expect the export to always be the same, regardless of the way it is called.

@mburggraf mburggraf added the type: bug A confirmed report of unexpected behavior in the application label Oct 28, 2021
@jeremystretch jeremystretch added the status: accepted This issue has been accepted for implementation label Dec 13, 2021
@jeremystretch jeremystretch self-assigned this Dec 13, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

2 participants