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

Extend module types to support modeling FRU components #10947

New Issue
Closed
opened 2025-12-29 21:38:11 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:38:11 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 25, 2025).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.2.6

Feature type

Data model extension

Proposed functionality

ModuleTypeProfile

Introduce a new ModuleTypeProfile model to represent a meta class of module types (e.g. power supply, NIC, or GPU). Each instance of this model will define a user-configurable schema of attributes to be assigned on module types having this profile.

class ModuleTypeProfile(NetBoxModel):
    name = models.CharField()
    schema = models.JSONField()

The schema field will hold a user-defined JSON schema which defines the scalar attributes that can be defined on module types with this profile. For example, a CPU profile might have a profile specify the following:

{
    "properties": {
        "architecture": {
            "type": "string"
        },
        "speed": {
            "type": "number",
            "minimum": "0.01",
            "multipleOf": "0.01"
        },
        "cores": {
            "type": "number",
            "minimum": 1,
            "multipleOf": 1
        }
    }
}

Note that these attributes are intentionally limited to storing the basic types supported by JSON schema (strings, numbers, booleans, and null). Any more advanced needs will require the use of a custom field on the ModuleType model.

ModuleType

Two new fields will be added to the ModuleType model:

  • profile: An optional ForeignKey to ModuleTypeProfile
  • attributes: A JSONField which stores the assigned key-value pairs for a module type as defined by the assigned profile

When editing a module type, the UI form will be extended to render all profile attributes as discrete form fields, with simple validation applied automatically.

Use case

The introduction of module type profiles with configurable attributes will improve the ability to accurately model field-replaceable units (FRU) as modules in NetBox. Today, this is typically done using inventory items, however that model is considerably limited in several ways:

  • Inventory items have no ability to track unoccupied bays/sockets
  • Inventory items (like other device components) must be named
  • Inventory items cannot contain components (interfaces, power ports, etc.)
  • There is no mechanism available for storing profile-specific attributes on inventory items

Modules are better suited for this task, as only the last constraint listed above affects modules as well, and is overcome by the changes proposed in this FR. (Ultimately, we'll likely deprecate inventory items in favor of this and related improvements to modules.)

Database changes

  • Introduce the ModuleTypeProfile model
  • Add a profile ForeignKey on ModuleType
  • Add an attributes JSONField on ModuleType

External dependencies

This will introduce a dependency in the jsonschema Python library.

Originally created by @jeremystretch on GitHub (Mar 25, 2025). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.2.6 ### Feature type Data model extension ### Proposed functionality ### ModuleTypeProfile Introduce a new ModuleTypeProfile model to represent a meta class of module types (e.g. power supply, NIC, or GPU). Each instance of this model will define a user-configurable schema of attributes to be assigned on module types having this profile. ```python class ModuleTypeProfile(NetBoxModel): name = models.CharField() schema = models.JSONField() ``` The `schema` field will hold a user-defined [JSON schema](https://json-schema.org/) which defines the scalar attributes that can be defined on module types with this profile. For example, a CPU profile might have a profile specify the following: ```json { "properties": { "architecture": { "type": "string" }, "speed": { "type": "number", "minimum": "0.01", "multipleOf": "0.01" }, "cores": { "type": "number", "minimum": 1, "multipleOf": 1 } } } ``` Note that these attributes are intentionally limited to storing the [basic types](https://cswr.github.io/JsonSchema/spec/basic_types/) supported by JSON schema (strings, numbers, booleans, and null). Any more advanced needs will require the use of a custom field on the ModuleType model. ### ModuleType Two new fields will be added to the ModuleType model: * `profile`: An optional ForeignKey to ModuleTypeProfile * `attributes`: A JSONField which stores the assigned key-value pairs for a module type as defined by the assigned profile When editing a module type, the UI form will be extended to render all profile attributes as discrete form fields, with simple validation applied automatically. ### Use case The introduction of module type profiles with configurable attributes will improve the ability to accurately model field-replaceable units (FRU) as modules in NetBox. Today, this is typically done using inventory items, however that model is considerably limited in several ways: * Inventory items have no ability to track unoccupied bays/sockets * Inventory items (like other device components) must be named * Inventory items cannot contain components (interfaces, power ports, etc.) * There is no mechanism available for storing profile-specific attributes on inventory items Modules are better suited for this task, as only the last constraint listed above affects modules as well, and is overcome by the changes proposed in this FR. (Ultimately, we'll likely deprecate inventory items in favor of this and related improvements to modules.) ### Database changes - Introduce the ModuleTypeProfile model - Add a `profile` ForeignKey on ModuleType - Add an `attributes` JSONField on ModuleType ### External dependencies This will introduce a dependency in the [`jsonschema`](https://python-jsonschema.readthedocs.io/en/stable/) Python library.
adam added the status: acceptedtype: featurecomplexity: medium labels 2025-12-29 21:38:11 +01:00
adam closed this issue 2025-12-29 21:38:11 +01:00
adam commented 2025-12-29 21:38:12 +01:00
Author
Owner
Copy Link

@marcusyuri commented on GitHub (Mar 25, 2025):

I would like to suggest that JSON Schema enum type was accepted in addition to the basic json schemas types.
This will be used to limit the user input to a pre-defined values choice.

One very common use case was to model transceivers. Today we use inventory itens to document transceivers, but most transceiver information can be specified using two enums - Ethernet Pmd (1000Base-T, 10GBASE-LR, ...) and Form Factor: (XFP, SFP, SFP+ ...), in addition the vendor part number field.

The module instance UI form can render an 'Selection Input Box' to choose from the json enum choices.

Also, I suggest that at least the 'required' keyword from json schema was accepted and enforced.

@marcusyuri commented on GitHub (Mar 25, 2025): I would like to suggest that JSON Schema enum type was accepted in addition to the basic json schemas types. This will be used to limit the user input to a pre-defined values choice. One very common use case was to model transceivers. Today we use inventory itens to document transceivers, but most transceiver information can be specified using two enums - Ethernet Pmd (1000Base-T, 10GBASE-LR, ...) and Form Factor: (XFP, SFP, SFP+ ...), in addition the vendor part number field. The module instance UI form can render an 'Selection Input Box' to choose from the json enum choices. Also, I suggest that at least the 'required' keyword from json schema was accepted and enforced.
adam commented 2025-12-29 21:38:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 26, 2025):

I would like to suggest that JSON Schema enum type was accepted in addition to the basic json schemas types.

Yep, this is supported by JSON schema. For example:

{
    "properties": {
        "supply": {
            "description": "Nature of the current delivered",
            "enum": [
                "AC",
                "DC"
            ],
            "title": "Supply type"
        }
    }
}
@jeremystretch commented on GitHub (Mar 26, 2025): > I would like to suggest that JSON Schema enum type was accepted in addition to the basic json schemas types. Yep, this is supported by JSON schema. For example: ```json { "properties": { "supply": { "description": "Nature of the current delivered", "enum": [ "AC", "DC" ], "title": "Supply type" } } }
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 complexity: medium status: accepted 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#10947
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?