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

Assign existing IP Address to Device Interface #1512

Closed
KWI-TFenby opened this issue Sep 19, 2017 · 25 comments
Closed

Assign existing IP Address to Device Interface #1512

KWI-TFenby opened this issue Sep 19, 2017 · 25 comments
Labels
type: feature Introduction of new functionality to the application

Comments

@KWI-TFenby
Copy link

KWI-TFenby commented Sep 19, 2017

Issue type

[] Feature request
[X] Bug report
[ ] Documentation

Environment

  • Python version: Python 3.4.5
  • NetBox version: v2.2-beta1

Description

From the device page, there's only the option to add a new IP address. From the IP address edit page, the "Interface Assignment" section is hidden. There is actually a workaround if you manually modify the IP address edit URL to include ?interface=x. If it isn't desirable to have the Interface Assignment section show up on every IP Address edit screen, it'd be nice to have a button on the Device page next to the current "New IP" one.

@candlerb
Copy link
Contributor

Related: #786, #1001, group thread

That thread says:

As interfaces can now be assigned to both devices and virtual machines, it becomes very difficult to specify interfaces without additional context. For instance, when creating an IP, you can assign it to an interface by searching for a device, by selecting a device (from a series of dropdowns), by searching for a virtual machine, or by selecting a virtual machine. It becomes very tedious and confusing to include all of these widgets in a single form.

Another option would be to allow linking an existing IP address to an interface, rather than vice versa. It might work like this:

  • When you click "Add address to interface" (on either a Device or VM) you get the same page as now
  • When you click Add, then the system searches for any existing address(es) with the same Address and VRF. If none are found, it just creates a new one as now, linked to this interface.
  • However, if one or more matching addresses are found, then it refreshes the page including a list of matches in a table, and offering the option to:
    • click on one of the existing addresses to link it to the this interface [^1]
    • create a new address anyway (this is only offered if the VRF allows duplicate addresses)

Alternate flow:

  • When you click "Add address to interface", you get a short form with Address, VRF and Search buttons only
  • After clicking Search, you get a new form:
    • Address and VRF displayed at top (non-editable)
    • Any existing matching IP addresses displayed in a table, with "Link to this address" button for each
    • Remaining fields for the Add Address page (Status, Role, Description, Tenancy... Create button). This section displayed only if the search returned no results, or the VRF allows duplicated IPs

[^1] If the address is already linked to another interface this should be indicated in the results table, but you can still take it over.

@candlerb
Copy link
Contributor

Just to be clear: the UI no longer appears to offer any way to assign an existing IP address object to an interface.

You have to delete the address, and recreate it when you add to an interface. This is inconvenient because it means all the information relating to that address has to be re-entered (Status, Role, Description, Tenancy etc); furthermore, the Address changes its API ID, and the Django history of changes to that object is lost.

A specific use case is when migrating from a flat IPAM spreadsheet to Netbox. Starting from a flat model you likely will import all the IP addresses first, and then later decide to create devices/vms/interfaces to attach them to.

@jeremystretch jeremystretch added the type: feature Introduction of new functionality to the application label Sep 25, 2017
@awerner
Copy link

awerner commented Sep 27, 2017

We're currently experiencing the use case @candlerb mentioned, using ?interface=X is a workaround, but it would be nice to have a way to do this without needing to resort manipulating the URL.

It would be also a nice workflow being able to select a free IP in the IPAM and then assing it to an interface when creating the IP address.

@phurrelmann
Copy link
Contributor

Additionally it is no longer possible to move an ip-address from one device to another without deleting and re-adding the ip-address.
IMHO this is not an enhancement but an regression, as functionality is lost

@dirtycajunrice
Copy link
Contributor

Both linked cases are closed. One should stay open until resolution correct?

@InsaneSplash
Copy link

I think this is also a bug and not a feature request.

@explody
Copy link
Contributor

explody commented Oct 27, 2017

I'll chime in and add that this really is a critical feature. I completely sympathize about the potential for an excessively cluttered dialog in attempting to associated interface/VM-interface back and forth to an IP. But, I would be willing to take slight clutter to (re)gain this feature.

The ability to cleanly find, (pre)create and associate IPs-to-interfaces and interfaces-to-IPs is well worth the complication IMHO. (I can give gory details on our live use cases if it's interesting)

@candlerb's ideas are minimal and the first is transparent, which is great. Here's another that involves user input but also provides good feedback to the user when creating or reassigning IPs

  • Add a prefix selector dropdown on the add-ip-address form, constrained to the prefixes associated with the device's site, perhaps grouped by VRF. This selector can be optional, and the IP field can still accept freeform IP/mask input. This has a side effect of allowing IP-in-prefix validation, at least on the user side, if a prefix is selected.
  • If a prefix is selected, the Address input field could have a widget akin to https://github.com/djk2/django-popup-view-field (which can render existing views and could be useful elsewhere as well), which would allow for selecting an existing IP. Constraining this to only when a prefix is selected dodges around an excessively large contents inside the widget. It also could give an opportunity for users to see free IPs inside a prefix, for selection rather than manual entry.

Since it's comparatively easy to reassign or even recreate IPs via the API, this mostly distills down to a UI/UX issue, IMHO. Honestly, not my strong suit but I do know the current UX is is very difficult for my engineers ;)

I'd be happy to help work on this.

@francoisbeaulieu
Copy link

Pardon my naïveté, but wouldn't the simplest solution be to redefine the VMs as a subcategory of devices, (say, by adding a column VM, which defaults to 'no', in the devices table) which would allow to populate the form's drop-down with only devices?

@candlerb
Copy link
Contributor

candlerb commented Nov 1, 2017

Devices and VMs already share the same Interface object.

The issue being discussed here is: (1) being able to assign an existing IP address to an interface; and (2) being able to move an existing IP address from one interface to another interface on a different device or VM.

Certainly, if you approach this from the IP Address side, you'd have to identify the interface to attach it to. This could be done simply by a search on the name, showing all Devices and VMs that the search matches. That's more convenient anyway than drilling down via Site -> Rack -> Device, or Cluster -> VM.

If you've already navigated to a particular Device->Interface or VM->Interface, then you just want to search for a particular IP address to attach to it.

@ckupe
Copy link

ckupe commented Nov 3, 2017

Adding my +1 to this issue. Was about to report this myself.

Before there was VM support, we had added "FQDN" and "Port Translation" custom fields to our IP objects. We also resorted to putting machine names in the Description so we could find their IPs.

When I started trying to connect all of the pre-existing IPs with these VMs, I discovered the fact that assignment of the IP is impossible from either end. Can't connect it by editing the IP, or can't connect it when creating the interface on the VM and trying to assign the IP.

I can see how this interaction is easily overlooked, but it has halted documentation. Without a way to at least bulk-import these interface creation+assignments or a way to link these objects, it's too tedious to delete and recreate IPs.

@GitRost
Copy link

GitRost commented Nov 3, 2017

Аnd me, you can also add to this issue.
Created in advance a lot of the right ip addresses and then was unpleasant surprised trying to assign them devices and ports!
I had to use a crutch "? interface = x"

@sylaan
Copy link

sylaan commented Nov 6, 2017

I am also affected by this. We have first migrated all our IPs into Netbox and then, as we add devices, we assign IPs to various interfaces. This is no longer possible since the last update.

I don't really understand why #1639 is marked as a duplicate of this and closed. It seems to me it's a severe loss of functionality. If the assigning of an IP to a device interface is supposed to be done now by editing the device, then this issue should be a bug since that's not possible.

@ckupe
Copy link

ckupe commented Nov 6, 2017

Until they fix this, the workaround is to append '?interface=###' to the URL where ### is the interface number referencing the device interface you need to connect. The options will appear.

This is still incredibly tedious though. I might just create a script button that hooks into the browser or a hack-job extension to do this in the meantime.

@candlerb
Copy link
Contributor

candlerb commented Nov 6, 2017

Just to be clear, you add this to the URL when you are editing the IP address. Example:

  • Navigate to /ipam/ip-addresses/9/edit/
  • Change this to /ipam/ip-addresses/9/edit/?interface=33 in the URL bar
  • Hit Enter to redraw the page. The correct interface should now be shown.
  • Click Save

And to find it's interface 33, you first need to navigate to the device or VM in question, and click the edit button (pencil) next to the interface.

@sylaan
Copy link

sylaan commented Nov 6, 2017

Yes, I am familiar with the workaround and I am using it. It works but it's extremely inconvenient, as already mentioned. I hope this will be solved soon. I am just very surprised this is treated as a feature request and not a bug.

@InsaneSplash
Copy link

Can we change this to a bug as this was available in a previous version?

@KWI-TFenby
Copy link
Author

We only just started using netbox, so I didn't even realize when reporting this that it was a regression, which it definitely is if this was possible in previous versions. This issue is the reason we've had to put our implementation on hold.

@InsaneSplash
Copy link

Yup, It has only been removed since the VM support was added.

@KWI-TFenby
Copy link
Author

Sweet! Testing now. Thank you @jeremystretch!

@candlerb
Copy link
Contributor

Works for me. Cheers!

@sylaan
Copy link

sylaan commented Nov 11, 2017

Awesome, thanks!

@InsaneSplash
Copy link

I upgraded to 2.2.5 and when I edit an IP address that is not linked to an interface it still does not provide the option to select a device/interface unless I use the work around of appending ?interface= to the URL?

@dirtycajunrice
Copy link
Contributor

@InsaneSplash it is now another tab. You will see the "add an IP address" vs find one at the top of the page after you click the green plus

@candlerb
Copy link
Contributor

That is: you can't do it directly from the IP address. Instead, you have to navigate to the device or VM where you want to attach the IP, then click the green plus next to the interface you want to attach it to, then use the tab as @dirtycajunrice says.

@dirtycajunrice
Copy link
Contributor

Still minor issue but created new issue #1718

@lock lock bot locked as resolved and limited conversation to collaborators Jan 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests