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

Add primary_for_parent to REST api ipam/ip-address #4011

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

Originally created by @agowa on GitHub (Aug 22, 2020).

Environment

  • Python version: I don't see it in the web interface, but DJANGO is 3.0.9 if that helps
  • NetBox version: v2.8.9

Proposed Functionality

Try to Update the ipaddress of an interface. When done through the webinterface there is an option to make that IP the primary one for the webinterface. When done through the PUT /api/ipam/ip-addresses/<ID>/ REST API it is not available.

Use Case

  1. Create an VM
  2. Create an interface and attach it to the VM
  3. Assign an ip address as primary on that interface (through the webinterface)
  4. Try to update any attribute (e.g. a tag) on that IP Address using the PUT /api/ipam/ip-addresses/<ID> REST API.

Currently the last step will fail if the IPAddress is already set as the primary ip (even though it is associated with the correct device.
It will result in an error like:
{"interface":["IP address is primary for virtual machine VM001 but assigned to VM001 (Network adapter 1)"]}

I looked at how the webinterface allows this to work and it has an additional flag that it passes to it's endpoint, namely primary_for_parent with an value of on representing a boolean.

It would be quite handy to have the same functionality via the REST api.

Another use case is when everything is created using the rest api, the logic for that is currently:

  1. Create VM
  2. Create Interface
  3. Create IPAddress and specify the interface
  4. Update the VM to reference the IPAddress as primary.

And than when the script is ran again it will fail with the above error, as the following logic is expected:

  1. Remove the IP from the VM
  2. Update the IPAddress object
  3. If necessary assign the IPAddress object to another interface
  4. Add the IP as primary again to the VM

While as the webinterface simply uses the first approach in all cases as it passes the flag of the IP Address being associated with the vm right along the update api call.

Relevant source code peaces:

Database Changes

none

External Dependencies

none

Originally created by @agowa on GitHub (Aug 22, 2020). ### Environment * Python version: I don't see it in the web interface, but DJANGO is 3.0.9 if that helps * NetBox version: v2.8.9 ### Proposed Functionality Try to Update the ipaddress of an interface. When done through the webinterface there is an option to make that IP the primary one for the webinterface. When done through the `PUT /api/ipam/ip-addresses/<ID>/` REST API it is not available. ### Use Case 1. Create an VM 2. Create an interface and attach it to the VM 3. Assign an ip address as primary on that interface (through the webinterface) 4. Try to update any attribute (e.g. a tag) on that IP Address using the `PUT /api/ipam/ip-addresses/<ID>` REST API. Currently the last step will fail if the IPAddress is already set as the primary ip (even though it is associated with the correct device. It will result in an error like: `{"interface":["IP address is primary for virtual machine VM001 but assigned to VM001 (Network adapter 1)"]}` I looked at how the webinterface allows this to work and it has an additional flag that it passes to it's endpoint, namely `primary_for_parent` with an value of `on` representing a boolean. It would be quite handy to have the same functionality via the REST api. Another use case is when everything is created using the rest api, the logic for that is currently: 1. Create VM 2. Create Interface 3. Create IPAddress and specify the interface 4. Update the VM to reference the IPAddress as primary. And than when the script is ran again it will fail with the above error, as the following logic is expected: 1. Remove the IP from the VM 2. Update the IPAddress object 3. If necessary assign the IPAddress object to another interface 4. Add the IP as primary again to the VM While as the webinterface simply uses the first approach in all cases as it passes the flag of the IP Address being associated with the vm right along the update api call. Relevant source code peaces: * https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/api/serializers.py#L243 * https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/forms.py#L594 * https://github.com/netbox-community/netbox/blob/develop/netbox/templates/ipam/ipaddress_edit.html#L46 ### Database Changes none ### External Dependencies none
adam closed this issue 2025-12-29 18:32:36 +01:00
adam commented 2025-12-29 18:32:36 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 24, 2020):

Pretty sure this is not-doable due to the way relations are handled in DJango with separate models and I don't think there is a way around it. The API for the most part interacts directly with the models and we don't have a lot of custom logic for it.

The proper way is to get the device and then set the primary ip based on the device. Unfortunately this requires 2 API calls instead of the one but is the best way to handle this without logic changes in the API scripts. At this point, I don't think we will take this up as a feature

@DanSheps commented on GitHub (Aug 24, 2020): Pretty sure this is not-doable due to the way relations are handled in DJango with separate models and I don't think there is a way around it. The API for the most part interacts directly with the models and we don't have a lot of custom logic for it. The proper way is to get the device and then set the primary ip based on the device. Unfortunately this requires 2 API calls instead of the one but is the best way to handle this without logic changes in the API scripts. At this point, I don't think we will take this up as a feature
adam commented 2025-12-29 18:32:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 31, 2020):

Agreed with @DanSheps. This operation requires two discrete steps: creating an IP address, and modifying a device to specify that IP as its primary address. Two different API endpoints are used for these functions.

@jeremystretch commented on GitHub (Aug 31, 2020): Agreed with @DanSheps. This operation requires two discrete steps: creating an IP address, and modifying a device to specify that IP as its primary address. Two different API endpoints are used for these functions.
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
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#4011
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?