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

Include device images in exported YAML #4292

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

Originally created by @fernandolcx on GitHub (Nov 21, 2020).

Environment

  • Python version: 3.9
  • NetBox version: 2.9.9

Proposed Functionality

Be able to import/export device models with their respective front/rear images.
Exported YAML will need to have an extra field containing their respective front/rear image, encoded in base64 (maybe?).

Use Case

Currently, the exported YAML for device models already carries all physical/logical information, so their respecitve images will be a plus, when migrating/exporting data between installations.

Database Changes

None that I'm aware of.

External Dependencies

I think base64 is native in Python so no external library will be necessary.

Originally created by @fernandolcx on GitHub (Nov 21, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/g/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.9 * NetBox version: 2.9.9 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Be able to import/export device models with their respective front/rear images. Exported YAML will need to have an extra field containing their respective front/rear image, encoded in base64 (maybe?). <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case Currently, the exported YAML for device models already carries all physical/logical information, so their respecitve images will be a plus, when migrating/exporting data between installations. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None that I'm aware of. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies I think base64 is native in Python so no external library will be necessary.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:34:27 +01:00
adam closed this issue 2025-12-29 18:34:27 +01:00
adam commented 2025-12-29 18:34:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 30, 2020):

To be clear, you're proposing that we embed base64-encoded image data within the YAML data? This would make these files incredibly difficult and tedious to modify by hand. It would also greatly complicate the logic and validation needed to import objects. Why not just reference the image by URL?

@jeremystretch commented on GitHub (Nov 30, 2020): To be clear, you're proposing that we embed base64-encoded image data _within_ the YAML data? This would make these files incredibly difficult and tedious to modify by hand. It would also greatly complicate the logic and validation needed to import objects. Why not just reference the image by URL?
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@fernandolcx commented on GitHub (Dec 2, 2020):

To be clear, you're proposing that we embed base64-encoded image data within the YAML data? This would make these files incredibly difficult and tedious to modify by hand.

I just use these YAML files to move data between installations so I never edit them, but for those who do I agree, It will be a mess.

It would also greatly complicate the logic and validation needed to import objects.

My initial proposal was to generate a single, consolidated file containing all the needed data to import.
If it's that complicated, we can consider exporting PNG/JPG files together with YAML file....

Why not just reference the image by URL?

... and reference it locally, right?

@fernandolcx commented on GitHub (Dec 2, 2020): > To be clear, you're proposing that we embed base64-encoded image data _within_ the YAML data? This would make these files incredibly difficult and tedious to modify by hand. I just use these YAML files to move data between installations so I never edit them, but for those who do I agree, It will be a mess. > It would also greatly complicate the logic and validation needed to import objects. My initial proposal was to generate a single, consolidated file containing all the needed data to import. If it's that complicated, we can consider exporting PNG/JPG files together with YAML file.... > Why not just reference the image by URL? ... and reference it locally, right?
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 2, 2020):

but for those who do I agree, It will be a mess

IMO this alone is justification enough to not pursue this feature request.

... and reference it locally, right?

Please clarify what you're asking.

@jeremystretch commented on GitHub (Dec 2, 2020): > but for those who do I agree, It will be a mess IMO this alone is justification enough to not pursue this feature request. > ... and reference it locally, right? Please clarify what you're asking.
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@fernandolcx commented on GitHub (Dec 2, 2020):

When we export device models, their respective images are not included. So when importing these files in new installations, we need to have these images on disk and upload them, by hand, one by one.

What I'm asking is if it's possible to include these images when exporting, be them encoded within YAML or separated PNG/JPG/SVG files.

@fernandolcx commented on GitHub (Dec 2, 2020): When we export device models, their respective images are not included. So when importing these files in new installations, we need to have these images on disk and upload them, by hand, one by one. What I'm asking is if it's possible to include these images when exporting, be them encoded within YAML or separated PNG/JPG/SVG files.
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 2, 2020):

I understand that. I'm not sure what you mean by the line quoted above.

@jeremystretch commented on GitHub (Dec 2, 2020): I understand that. I'm not sure what you mean by the line quoted above.
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@fernandolcx commented on GitHub (Dec 2, 2020):

I understand that. I'm not sure what you mean by the line quoted above.

Something like this:

---
 manufacturer: 3Com
 model: SuperStack 3 4500 PWR
 slug: superstack-3-4500-pwr
 part_number: 3CR17572-91
 u_height: 1
 images: 
 - side: "front"
   file: "3com-4500-pwr_front.png"
   size: 64241
   md5sum: "d37740dbf9fdba01723074357919f991"
   format: "png"
 - side: "rear"
   file: "3com-4500-pwr_rear.png"
   size: 64587
   md5sum: "5478540dbf9fdba0172385757919f991"
   format: "png"

When I say "locally" I mean that the image is stored locally rather in a remote location, and it needs to be uploaded together with YAML file.

@fernandolcx commented on GitHub (Dec 2, 2020): > I understand that. I'm not sure what you mean by the line quoted above. Something like this: ```yaml --- manufacturer: 3Com model: SuperStack 3 4500 PWR slug: superstack-3-4500-pwr part_number: 3CR17572-91 u_height: 1 images: - side: "front" file: "3com-4500-pwr_front.png" size: 64241 md5sum: "d37740dbf9fdba01723074357919f991" format: "png" - side: "rear" file: "3com-4500-pwr_rear.png" size: 64587 md5sum: "5478540dbf9fdba0172385757919f991" format: "png" ``` When I say "locally" I mean that the image is stored locally rather in a remote location, and it needs to be uploaded together with YAML file.
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 2, 2020):

I'd expect it to be a URL, so starting with either https:// (or similar) for a remote file, or file:// for something local.

However, extending the YAML import logic to include this would not be trivial. How often are you importing/exporting device types anyway?

@jeremystretch commented on GitHub (Dec 2, 2020): I'd expect it to be a URL, so starting with either `https://` (or similar) for a remote file, or `file://` for something local. However, extending the YAML import logic to include this would not be trivial. How often are you importing/exporting device types anyway?
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@fernandolcx commented on GitHub (Dec 2, 2020):

How often are you importing/exporting device types anyway?

I work for a network consulting company focused on ISP clients.
I think at least once a week I need to create a new device and generate their images by drawing or extracting from Visio stencils.

@fernandolcx commented on GitHub (Dec 2, 2020): > How often are you importing/exporting device types anyway? I work for a network consulting company focused on ISP clients. I think at least once a week I need to create a new device and generate their images by drawing or extracting from Visio stencils.
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 17, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Jan 17, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:34:28 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 2, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Feb 2, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review type: feature
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#4292
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?