mirror of
https://github.com/netbox-community/netbox.git
synced 2026-01-21 02:58:43 -06:00
Add documentation for {module_path} placeholder
Per arthanson's review request, updated docs/models/dcim/moduletype.md
to document:
- {module} placeholder behavior (single vs multiple use)
- {module_path} placeholder for full path expansion
- Position field resolution for nested module bays
This commit is contained in:
@@ -16,9 +16,33 @@ Note that device bays and module bays may _not_ be added to modules.
|
|||||||
|
|
||||||
## Automatic Component Renaming
|
## Automatic Component Renaming
|
||||||
|
|
||||||
When adding component templates to a module type, the string `{module}` can be used to reference the `position` field of the module bay into which an instance of the module type is being installed.
|
When adding component templates to a module type, placeholders can be used to dynamically incorporate the module bay's `position` field into component names. Two placeholders are available:
|
||||||
|
|
||||||
For example, you can create a module type with interface templates named `Gi{module}/0/[1-48]`. When a new module of this type is "installed" to a module bay with a position of "3", NetBox will automatically name these interfaces `Gi3/0/[1-48]`.
|
### `{module}` Placeholder
|
||||||
|
|
||||||
|
The `{module}` placeholder references the position of the parent module bay:
|
||||||
|
|
||||||
|
* **Single use**: Expands to the immediate parent's position only
|
||||||
|
* **Multiple uses**: Each `{module}` token is replaced level-by-level (the number of tokens must match the nesting depth)
|
||||||
|
|
||||||
|
For example, a module type with interface templates named `Gi{module}/0/[1-48]`, when installed in a module bay with position "3", will create interfaces named `Gi3/0/[1-48]`.
|
||||||
|
|
||||||
|
### `{module_path}` Placeholder
|
||||||
|
|
||||||
|
The `{module_path}` placeholder expands to the full path from the root device to the current module, with positions joined by `/`. This is useful for modules that can be installed at any nesting depth without modification.
|
||||||
|
|
||||||
|
For example, consider an SFP module type with an interface template named `eth{module_path}`:
|
||||||
|
|
||||||
|
* Installed directly in slot 2: creates interface `eth2`
|
||||||
|
* Installed in slot 1's nested bay 1: creates interface `eth1/1`
|
||||||
|
* Installed in slot 1's nested bay 2's sub-bay 3: creates interface `eth1/2/3`
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
`{module_path}` can only be used once per template attribute, and cannot be mixed with `{module}` in the same attribute.
|
||||||
|
|
||||||
|
### Position Field Resolution
|
||||||
|
|
||||||
|
The `{module}` placeholder can also be used in the `position` field of [module bay templates](./modulebaytemplate.md) defined on a module type. This allows nested module bays to build hierarchical position values. For example, a module bay template with `position="{module}/1"`, when its parent module is installed in a bay with position "2", will have its position resolved to "2/1".
|
||||||
|
|
||||||
Automatic renaming is supported for all modular component types (those listed above).
|
Automatic renaming is supported for all modular component types (those listed above).
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user