Skip to content

Extend module types to support modeling FRU components #19002

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

Closed
jeremystretch opened this issue Mar 25, 2025 · 2 comments
Closed

Extend module types to support modeling FRU components #19002

jeremystretch opened this issue Mar 25, 2025 · 2 comments
Assignees
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@jeremystretch
Copy link
Member

jeremystretch commented Mar 25, 2025

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.

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release status: under review Further discussion is needed to determine this issue's scope and/or implementation type: feature Introduction of new functionality to the application labels Mar 25, 2025
@marcusyuri
Copy link

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.

@jeremystretch jeremystretch self-assigned this Mar 25, 2025
@jeremystretch jeremystretch added this to the v4.3 milestone Mar 25, 2025
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation complexity: medium Requires a substantial but not unusual amount of effort to implement and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation needs milestone Awaiting prioritization for inclusion with a future NetBox release labels Mar 25, 2025
@jeremystretch
Copy link
Member Author

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"
        }
    }
}

jnovinger pushed a commit that referenced this issue Apr 1, 2025
* Move Module & ModuleType models to a separate file

* Add ModuleTypeProfile & related fields

* Initial work on JSON schema validation

* Add attributes property on ModuleType

* Introduce MultipleOfValidator

* Introduce JSONSchemaProperty

* Enable dynamic form field rendering

* Misc cleanup

* Fix migration conflict

* Ensure deterministic ordering of attriubte fields

* Support choices & default values

* Include module type attributes on module view

* Enable modifying individual attributes via REST API

* Enable filtering by attribute values

* Add documentation & tests

* Schema should be optional

* Include attributes column for profiles

* Profile is nullable

* Include some initial profiles to be installed via migration

* Fix migrations conflict

* Fix filterset test

* Misc cleanup

* Fixes #19023: get_field_value() should respect null values in bound forms (#19024)

* Skip filters which do not specify a JSON-serializable value

* Fix handling of array item types

* Fix initial data in schema field during bulk edit

* Implement sanity checking for JSON schema definitions

* Fall back to filtering by string value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

2 participants