Schema has no way to express module bay types (NetBox 4.7)

[roc-ops]

NetBox 4.7 added the ability to restrict which module types may be installed in
a module bay — when at least one bay type is set on a module bay, only module
types sharing a common bay type can be installed
(netbox-community/netbox#19731).

The library schema has no field for this. module-bay in
schema/components.json is:

{ "name": "...", "label": "...", "position": "...", "description": "..." }

with "additionalProperties": false, and moduletype.json has no bay-type
field either.

So a device type or module type imported from this library arrives with the
constraint unset, and it has to be applied by hand afterwards — which is the
part that does not scale, since it is per-bay on every device.

Could the schema gain the corresponding field(s) on module-bay and
moduletype, so a definition can carry what the bay accepts?

Happy to open a PR once the shape is agreed.

[harryajc]

Hi @roc-ops thank you for bringing this up, I had realised that they had added this. I'll have a look at it shortly.

[harryajc]

@roc-ops What is the schema for these new module types? I haven't been able to find any documentation on it yet

[roc-ops]

@harryajc The docs exist but aren't on main or develop yet — they're only on the
feature branch, since 4.7 is still in beta (v4.7.0-beta2). That's
docs/models/dcim/modulebaytype.md, added by
netbox#22648 (merged 2026-07-14).
Worth noting the v4.7.0 milestone is due 2026-09-01 and currently sits at 0 open / 72
closed, so this is days away rather than months.

Summarising it here so it's all in one place:

The model. ModuleBayType is a new first-class PrimaryModel in dcim, with:

field	notes
name	e.g. LC Line Card, Power Supply, Fan Tray
slug	URL-friendly identifier
manufacturer	FK, optional — for vendors with proprietary slot designations
color	label colour
description, comments	plus the usual tags / custom fields / changelog

Where it attaches. It's an M2M called module_bay_types on three models:

• ModuleBay (the component)
• ModuleBayTemplate (the template) — this is the one the library instantiates
• ModuleType

The rule. If both the bay and the module type being installed carry at least one
bay type, installation is allowed only if the two sets intersect. If either side has
none, no constraint is applied — so existing data is unaffected.

API shape. module_bay_types is a nested list on the serializers for all three
models, e.g. ModuleBayTemplateSerializer and ModuleTypeSerializer.

---

For the library, the constraint is an allow-list of labels shared between a bay and the
module types that fit it, so both sides need to name the same thing. The closest
existing precedent is profile on moduletype.json, which references
ModuleTypeProfile by plain string and lets the importer resolve it. Following that:

module-bay in schema/components.json:

"module_bay_types": {
  "type": "array",
  "items": { "type": "string" },
  "uniqueItems": true
}

and the same key on moduletype.json. In YAML:

# device-types/Acme/ACME-9000.yaml
module-bays:
  - name: Slot 1
    position: "1"
    module_bay_types: [line-card]
  - name: PSU 1
    position: "psu1"
    module_bay_types: [power-supply]

# module-types/Acme/ACME-LC-48X.yaml
manufacturer: Acme
model: ACME-LC-48X
module_bay_types: [line-card]

One design question I don't think has an obvious answer: should the referenced bay type
be scoped to the manufacturer or global? ModuleBayType.manufacturer is optional, and
both readings are defensible — a proprietary slot designation clearly belongs to its
vendor, but something like pcie-x8 or qsfp-dd is the same thing everywhere and would
be better shared than duplicated per vendor. Since library files already sit under a
manufacturer directory, scoping by default would be implicit and free, but it would make
cross-vendor types awkward to express.

If you'd rather the definitions be self-contained instead of referenced by slug, the
alternative is inlining {name, slug, manufacturer} at each use, at the cost of
repeating it on every bay.

Happy to open a PR once you've picked a direction — including a module_bay_types
validation step if that's wanted. No rush from my side beyond the obvious: until the
schema carries it, anything imported onto 4.7 arrives with the constraint unset and has
to be set by hand per bay, which is the case the original issue was about.

[marcinpsk]

hi,
@roc-ops sorry, I saw you were volunteering for a PR only after I've made one - please have a look
@harryajc have a look, works for me - but maybe I'm missing something - and I didn't add workflow change to not put it together (one to allow contributions to new directory without CI label)