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

Create device during IP creation,import #601

New Issue
Closed
opened 2025-12-29 16:23:43 +01:00 by adam · 5 comments
adam commented 2025-12-29 16:23:43 +01:00
Owner
Copy Link

Originally created by @den-is on GitHub (Jan 4, 2017).

Hello,

My company is trying to migrate from ancient IPAM solution to NetBox, which in general we like and thanks for your tremendous work.
But we found that at some point process of IP creation import is quite explicit, detailed and finally cumbersome.
I will try to explain it.
We have couple racks, only dozen physical devices, and several hundreds of virtual instances.

Right now admin to add ip address, has to complete several actions on different pages and dialogues:

  1. make sure that DeviceRole, Manufacture, Type, Site, Rack are in place and properly configured
  2. create device on devices page
  3. add interface to just added device by entering it's page
  4. add IP address with selected device
  5. Finally, assign device+interface to just created IP address

From one side it's understandable to have such explicit process of registering IP address, separation of concepts etc..
From other side in some cases like one I have described above it is too explicit and implies "click-to-death" technique. Application has no flexibility.
Some netbox attributes for "Virtual Machine" devices can be skipped like site, rack, interface.

Couple thoughts for help:

  • Maybe some Device template mechanism can be added.
    Example: IP_address + flag-on-off + device_name + dev_template will automatically create device with some default values like "interface!, type, ..."
  • Add device during IP creation only by name, which will add some interface on it's own and assign IP to it
  • IMO less favorable option. move complete device creation form as option, into address creation form. Creating some smarter creation wizard.
Originally created by @den-is on GitHub (Jan 4, 2017). Hello, My company is trying to migrate from ancient IPAM solution to NetBox, which in general we like and thanks for your tremendous work. But we found that at some point process of IP creation import is quite explicit, detailed and finally cumbersome. I will try to explain it. We have couple racks, only dozen physical devices, and several hundreds of virtual instances. Right now admin to add ip address, has to complete several actions on different pages and dialogues: 1. make sure that DeviceRole, Manufacture, Type, Site, Rack are in place and properly configured 2. create device on devices page 3. add interface to just added device by entering it's page 4. add IP address with selected device 5. Finally, assign device+interface to just created IP address From one side it's understandable to have such explicit process of registering IP address, separation of concepts etc.. From other side in some cases like one I have described above it is too explicit and implies "click-to-death" technique. Application has no flexibility. Some netbox attributes for "Virtual Machine" devices can be skipped like site, rack, interface. Couple thoughts for help: - Maybe some `Device template` mechanism can be added. Example: `IP_address + flag-on-off + device_name + dev_template` will automatically create device with some default values like "interface!, type, ..." - Add device during IP creation only by name, which will add some interface on it's own and assign IP to it - IMO less favorable option. move complete device creation form as option, into address creation form. Creating some smarter creation wizard.
adam closed this issue 2025-12-29 16:23:43 +01:00
adam commented 2025-12-29 16:23:43 +01:00
Author
Owner
Copy Link

@Armadill0 commented on GitHub (Jan 4, 2017):

Seems like a variation of #665?

@Armadill0 commented on GitHub (Jan 4, 2017): Seems like a variation of #665?
adam commented 2025-12-29 16:23:44 +01:00
Author
Owner
Copy Link

@den-is commented on GitHub (Jan 4, 2017):

Yep, looks related

@den-is commented on GitHub (Jan 4, 2017): Yep, looks related
adam commented 2025-12-29 16:23:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 4, 2017):

Maybe some Device template mechanism can be added.

This is what device types are. You define a type of device and all the appropriate interfaces and other hardware resources are created automatically upon instantiation.

Add device during IP creation only by name, which will add some interface on it's own and assign IP to it

In order to create a device, you must tell NetBox what type it is and where it is located. Trying to force all of that information into a single operation is cumbersome and unnecessary.

Some netbox attributes for "Virtual Machine" devices can be skipped like site, rack, interface.

NetBox does not currently support the concept of virtual machines (see #142). Attempting to represent virtual machines in the current data model will result in a poor experience.

The process for what you want to do is pretty straightforward:

  1. Create the device types for all the devices you'll create.
  2. Create or import all your racks.
  3. Create or import all your devices.
  4. Import all your IP addresses.

This layered approach makes it very simple to import objects in bulk. It isolates unrelated definitions from one another and ensures that the necessary validation occurs at natural points in the process.

@jeremystretch commented on GitHub (Jan 4, 2017): > Maybe some Device template mechanism can be added. This is what device types are. You define a type of device and all the appropriate interfaces and other hardware resources are created automatically upon instantiation. > Add device during IP creation only by name, which will add some interface on it's own and assign IP to it In order to create a device, you must tell NetBox what type it is and where it is located. Trying to force all of that information into a single operation is cumbersome and unnecessary. > Some netbox attributes for "Virtual Machine" devices can be skipped like site, rack, interface. NetBox does not currently support the concept of virtual machines (see #142). Attempting to represent virtual machines in the current data model will result in a poor experience. The process for what you want to do is pretty straightforward: 1. Create the device types for all the devices you'll create. 2. Create or import all your racks. 3. Create or import all your devices. 4. Import all your IP addresses. This layered approach makes it very simple to import objects in bulk. It isolates unrelated definitions from one another and ensures that the necessary validation occurs at natural points in the process.
adam commented 2025-12-29 16:23:44 +01:00
Author
Owner
Copy Link

@den-is commented on GitHub (Jan 4, 2017):

This is what device types are. You define a type of device and all the appropriate interfaces and other hardware resources are created automatically upon instantiation.

Okay, thanks for pointing on that. overlooked "device type"'s ability to add interfaces. But still I was talking about different type of templates. Higher lvl device templates which will combine everything that device has and only will be waiting "device name" from user. Imo nothing cumbersome here.

NetBox does not currently support the concept of virtual machines (see #142). Attempting to represent virtual machines in the current data model will result in a poor experience.

😕 ...
I'm happy with my current type Virtual Machine which is 0U high and attached manufacture for example is VMware.
And devices are placed in rack called VMWARE which is 1U high for experiment and hosts 10 devices already. Rack which I will never look into.

My suggested process looks like

  1. Open IP address dialogue - enter IP
  2. In same dialogue assign to device - select checkbox create from template - enter device name - select device template (which has device type, rack, site, ... )
  3. Press OKAY

Voila - you have new IP address attached to some new virtual device which was created at the same time.
This is just option which is enabled by user. Of course story is different for real devices which will be carefully inserted into netbox in proper racks with all other details

@den-is commented on GitHub (Jan 4, 2017): > This is what device types are. You define a type of device and all the appropriate interfaces and other hardware resources are created automatically upon instantiation. Okay, thanks for pointing on that. overlooked "device type"'s ability to add interfaces. But still I was talking about different type of templates. Higher lvl device templates which will combine everything that device has and only will be waiting "device name" from user. Imo nothing cumbersome here. > NetBox does not currently support the concept of virtual machines (see #142). Attempting to represent virtual machines in the current data model will result in a poor experience. 😕 ... I'm happy with my current type `Virtual Machine` which is 0U high and attached manufacture for example is `VMware`. And devices are placed in rack called `VMWARE` which is 1U high for experiment and hosts 10 devices already. Rack which I will never look into. My suggested process looks like 1. Open IP address dialogue - enter IP 2. In same dialogue assign to device - select checkbox `create from template` - enter device name - select device template (which has device type, rack, site, ... ) 3. Press OKAY Voila - you have new IP address attached to some new virtual device which was created at the same time. This is just option which is enabled by user. Of course story is different for real devices which will be carefully inserted into netbox in proper racks with all other details
adam commented 2025-12-29 16:23:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 4, 2017):

Why would you want a template that specifies a specific device type in a specific rack? That's of extremely limited use. Practically speaking, you're almost always going to want to choose a device's rack, role, and so on; there's very little value in creating another layer of abstraction above the device type.

I think you're trying to push the concept of templating too far to work with virtual machines, which as I've pointed out aren't supported yet. I'm going to close out this issue as I don't see anything actionable.

@jeremystretch commented on GitHub (Jan 4, 2017): Why would you want a template that specifies a specific device type in a specific rack? That's of extremely limited use. Practically speaking, you're almost always going to want to choose a device's rack, role, and so on; there's very little value in creating another layer of abstraction above the device type. I think you're trying to push the concept of templating too far to work with virtual machines, which as I've pointed out aren't supported yet. I'm going to close out this issue as I don't see anything actionable.
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#601
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?