Creating a New Node Definition¶
Introduction
A node definition in Cisco Modeling Labs represents a type of virtual device. Each node in a CML lab has an associated node definition. For example, in the Workbench, when you drag-and-drop IOSv from the Add Nodes drawer to the lab, CML adds a node that has an associated node definition of IOSv. If you drag-and-drop CSR1000v onto the lab, CML adds another node to the lab with an associated node definition of CSR1000v. The Add Nodes drawer shows an item for each node definition that is visible. Being visible is one of the properties of the node definition.
It is important to understand that the node definition represents a family or type of virtual device, with information on how to run it in CML. It is not a particular node image, which is one or a few files that contain a packaged release of the software and data that actually runs in the lab node.
A node image in CML has an image definition. Among other things, the image definition associates the node image with a particular node definition. For example, if your administrator has added multiple versions of IOS XR 9000v to your CML server, then you will have multiple image definitions, one per image file, but each image would be associated with the same built-in IOS XR 9000v node definition.
If you do not select a specific image for a node in your lab, that node will use the default image of its associated node definition. Creating a new image definition for a custom node image is required in order to use it in lab nodes. See Custom Node Images for more information on node images.
Creating a custom node definition for a new type of virtual device is more complicated. The node definition details all of the properties that enable Cisco Modeling Labs to start a VM that’s associated with the node definition. To create a custom node definition, you should understand the virtualization details for that type of virtual device. This guide describes the node definition properties in CML, and you should use it in conjunction with your virtual device’s installation and configuration documentation to select correct values for your custom node definition.
The following sections correspond to the node definition editor UI sections, which you can use to create or edit the node definition. You can also edit and import the node definition attributes as a YAML file with the same structure of sections, attributes and values.
General Settings
Property name |
Required? |
Description |
|---|---|---|
ID |
yes |
A unique identifier for the node definition. Your CML server cannot have two node definitions with the same ID. The ID must not contain spaces. For example, “exampleco-rtr”. |
Description |
no |
A free-form description of this node type. |
Nature |
yes |
This property describes the role that nodes using this node definition play in the network. Pick the value from the drop-down that most closely matches this type of device. |
User Interface Settings
This section sets up behavior and representation of the nodes in user interfaces.
The icon property value can be either a pre-defined name from a bundled list of icons, or you can select the “custom” item from the dropdown and load a custom image file into your browser, which can preview and set the actual icon value accordingly. The custom icon value is technically a data URL, a textual representation of a small file commonly used in web pages. The value consists of:
the constant identifying a data URL and its media type
data:image/the matching image type, the only allowed values are
png,jpegandsvg+xmlthe constant encoding indicator
; base64,the encoded binary image file data using the base64 encoding
The uploaded image file data is passed to browsers as-is, and thus must be recognized and validated by browsers for the icon to be displayed properly. It must be at most 100 KB in size and only one of the three supported types. Use SVG if possible to have the best visual experience when scaling the lab topology view.
Property Name |
Required? |
Description |
|---|---|---|
Visible |
yes |
This property permits you to reduce the number of items shown in the Add Nodes drawer in the Workbench. The Add Nodes drawer shows an item for a node definition if and only if visible is true. In general, you should enable this property. |
Description |
no |
A description of the node definition that also supports Markdown mark-up for rich formatting. |
Prefix |
yes |
A prefix used to name nodes associated with this node definition. When you add a node to the lab, CML will supply a default label for the node by appending a numeric value to the prefix. For example, new IOSv nodes are named “iosv-1”, “iosv-2”, “iosv-3”, etc. The prefix value should be a sequence of letters, numbers, and dashes ending with a dash. For example, “exampleco-rtr-“. |
Icon |
yes |
The icon to assign this node. Choose from the list based on what this node most closely resembles, or set an image data URL containing a small image (see above). This choice is a matter of taste and only affects the visual display of your lab and has no impact on the simulation. |
Label |
yes |
The label is used for the item in the Add Nodes drawer in the Workbench. This label should be short and human-readable, such as “ExampleCo Rtr”. |
Linux Native Simulation Settings
This is the section details all of the virtualization properties. Be sure to have your virtual device’s installation and configuration documentation to help you set the correct values. Many of these settings only apply to KVM nodes, where the value is ignored in IOL and Docker nodes, and you may pick any value if a value is formally required and there is no specific recommendation for the value below.
Similar settings for Docker node definitions are rather specified as a special day-0 file in the Configuration section below.
Property Name |
Required? |
Description |
|---|---|---|
Domain Driver |
yes |
The virtualization driver for this node. |
Simulation Driver |
yes |
The CML simulation driver profile. This property is not currently used, hence choosing “server” in case nothing better matches is appropriate. |
Disk Driver |
yes |
The type of disk device to add. Refer to your device’s installation and configuration documentation to choose the most appropriate type. Ignored by Docker and IOL. |
Memory (MiB) |
yes |
The amount of memory (in megabytes) that CML should allocate to nodes associated with this node definition. Refer to your device’s installation and configuration documentation to choose the correct value. |
CPUs |
yes |
The number of virtual CPUs that CML should allocate to nodes associated with this node definition. Refer to your device’s installation and configuration documentation to choose the correct value. |
CPU Limit |
yes |
A percentage value that can be used to limit the amount of CPU allocated to nodes associated with this node definition. See Launch Sequence and CPU Limiting. Start with a value of 100%, and adjust later if needed. |
CPU Model |
no |
A model specification for a KVM virtual CPU, with an optional comma-separated set
of CPUID feature flags. Refer to your device’s installation and configuration
documentation to choose the correct value, in case the default does not work.
The default exposes the actual CPU of the CML server to the VM. Which CPU
models and flags are available may depend on the actual CPU. The list of supported
values on any given host is printed by the |
Machine Type |
no |
A virtual machine standard model. The common suitable values are |
Trusted Platform Module |
no |
Enable a simulated Trusted Platform Module device, required for UEFI Secure Boot. Ignored by Docker and IOL, do not set a value. |
Random Number Generator |
no |
Enable a simulated Random Number Generator device; some specific VMs need it disabled. Most VMs should leave it enabled. Many in-node operations such as cryptographic key generation depend on such random number sources and work improperly without them. Ignored by Docker and IOL, do not set a value. |
Network Driver |
yes |
The network driver type for nodes associated with this node definition. Refer to your device’s installation and configuration documentation to choose the correct value. Ignored by Docker and IOL. |
Data Disk Size (GiB) |
no |
The size of the data disk required by nodes associated with this node definition (in gigabytes). The data disk is an additional disk that CML adds to the virtual device if a non-zero value is provided. Some devices need a second disk to store databases or other information. For example, the SD-WAN manager stores its database on the second disk. Refer to your device’s installation and configuration documentation to see whether this type of device requires a second disk and, if so, what size. Ignored by Docker and IOL, do not set a value. |
Boot Disk Size (GiB) |
no |
The size of the boot disk required by nodes associated with this node definition (in gigabytes). The boot disk is typically the disk that holds the operating system and that is marked bootable. Refer to your device’s installation and configuration documentation to choose the correct value. Ignored by Docker and IOL, do not set a value. |
Video Model |
no |
This property specifies the video card inserted into the virtual device. This
probably can usually be left with the default value. Some devices might require
a specific model to be set.
For typical use, either choose std or cirrus. If the device type does not require
a video card, such as a router that relies on a serial console for configuration
management access, you may choose |
Video Memory (MiB) |
no |
If this device will have a graphical desktop or use a graphical console (even if that graphical console is just a text interface), you must set this property to a non-zero value. The value specified in MB, and a value of 16 or 32 is common for device types that correspond to hosts. Refer to your device’s installation and configuration documentation when choosing a value. Devices that have a heavier graphical interface require more video memory. Ignored by Docker and IOL, do not set a value. |
EFI Boot |
no |
If device requires UEFI to boot, enable this option. Ignored by Docker and IOL. |
EFI Code |
no |
If device requires UEFI to boot, and a custom EFI code file will be present in image definitions associated with the node definition, put the name of the file here. Ignored by Docker and IOL, do not set a value. |
EFI Vars |
no |
If device requires UEFI to boot, and a custom EFI vars file will be present in image
definitions associated with the node definition, put the name of the file here.
A special value |
Note: Disk sizes (data disk and boot disk) override the size of the disk itself. For example, a boot disk image that is associated with a specific device might have a configured disk size of 16GB, but the actual file size might be less than 16GB. It will never be larger than the specified size.
In this example, the disk image file on the CML server that corresponds to the disk associated with a particular node is not necessarily 16GB. The virtual disk inside of the disk image file is simply configured to have the specified size. An entirely empty qcow2 disk image file for a 1 TB disk might only be a few kilobytes in size.
When the boot disk size for a virtual router/server device is specified as 32GB, then the system will increase the size of the virtual disk from its initial size of 16GB to 32GB when it is first instantiated on the hypervisor. This change in size does not automatically increase file-systems or partition tables. The operating system for that particular virtual device type must take advantage of the additional space from the larger disk size.
Note: For EFI boot to work with a custom definition, each CML host requires at least an EFI Code file and optionally a Vars file associated with the definition. Both files may then be present in each associated image definition directory, where the names of the files can be entered in the node definition.
By default, if you enable EFI booting, CML will select a built-in pair of OVMF
project’s generic EFI images. If the TPM flag is enabled for the node definition,
a secureboot version is selected. These files are suitable for most node types.
Alternatively, custom files can be placed on each CML host under the sub-directory
of /usr/share/edk2/ovmf/, named the same as the node definition ID. Put the files
named efi_code.fd and efi_vars.fd into this directory, and leave the node
definition fields blank. If the EFI files are always the same as in some pre-existing node
definition, you can add a symbolic link named as the new ID to the old node definition ID,
or you can set the efi_code value to the ID of the other definition.
There is no UI/API support for adding EFI files for either of the definition types.
Estimated Resource Usage
This section contains the expected normal resource usage of nodes when they run. Nodes ideally do not use all of the resources they get allocated. These values can be used to estimate whether the node is consuming an unexpected amount of resources. This functionality is currently very limited in CML, and you do not need to specify any values in this section at this time.
Interfaces Settings
This section will also require you to consult your device’s system requirements or installation and configuration documentation to understand what the default interfaces and the maximum number of interfaces are. You will need the minimum and maximum interface counts plus the naming convention of the interfaces. If your virtual device uses a serial console, you can provide that information in this section.
Property Name |
Required? |
Description |
|---|---|---|
Has a Loopback Interface |
yes |
If this device should have a loopback interface, enable this option. Otherwise, disable it. |
Loopback Name |
no |
If the device has a loopback interface, specify its name here. For example, the loopback on a Linux hosts would be lo. |
Number of serial ports |
yes |
The total number of serial ports this type of virtual device has. Even if the device does not have any serial ports, such as a console port, this property should not be 0. It must be a number between 1 and 8 (inclusive). Cisco devices typically have two serial ports: a console port and an aux port. Linux hosts may use a serial port as the text console. Docker nodes have at least one (read-only) serial console as well. In general, set this property to 1 unless your virtual device’s installation and configuration documentation indicates that the device can support more than one. |
Default serial port for console |
no |
The port number which should be used by default for console access, starting with the default port number zero. |
Minimal number of physical interfaces |
no |
The minimum number of interfaces to always attach to a node when it starts. Set this number to indicate that the node will fail to work properly or even boot without these interfaces. Even if you delete interfaces from a node, this number will be created anyway, at the latest when you start it the first time. |
Default number of physical interfaces |
no |
The number of network interfaces to attach to a new node by default. While the property is optional, you will typically specify a number here. The minimum value is the same as the minimal count. Allocating a few interfaces by default can be useful if nodes associated with this node definition typically have multiple connections in your labs, but you can always add additional interfaces to a node before you start it the first time–up to its node definition’s maximum number of interfaces–after you add the node to your lab in the Workbench. See also Node Interfaces. |
Note: A loopback interface is only needed for router / device configuration generation. It also only applies to node definitions for which the bootstrap configuration is implemented. It does not affect the configuration provisioning functions in any way. It does not appear as a connect-able device in the topology diagram!
Next, you should provide all of the potential interface names the device can have.
This list should include the default interfaces. Enter the name of the first interface
in the interface name field, such as eth0 or GigE0/0. If your device’s interface names
simply have a numerical suffix, such as eth0, eth1, and eth2, you can simply enter
eth0 in the interface name field and then click the Increment Last Interface,
button twice to automatically add eth1 and eth2. If your device’s interface names are
not incremental, use the Add Interface button to add additional empty fields
and enter the interface names in those fields manually.
It is important to list all of the interfaces this type of device can have. CML will prevent you from adding more interfaces to a node than the number of interfaces in its associated node definition. The interface names are also important so that the labels shown with a lab in the Workbench match what you see in the configuration for your device’s VM. The VM’s operating system assigns names to the sequence of node interfaces following its own rules, most likely always giving them names in the same sequence. The node definition should capture the resulting list; it cannot change the OS’s rules to force any different names on the interfaces.
Boot Settings
Property Name |
Required? |
Description |
|---|---|---|
Timeout (seconds) |
yes |
The timeout in seconds that CML should wait for the node to boot fully. The value is the maximum time (in seconds) that CML will wait before the node’s in-progress status will change to booted, and the Workbench will show the node with a solid green dot. |
You can optionally click the Add Boot Line button to add additional boot lines. CML will scan the node’s console during boot, checking to see whether a line contains each boot string. Boot lines are evaluated as regular expressions. Once any of the boot lines has been seen, CML will consider the node to be fully booted. For example, IOSv nodes include “%PLATFORM-5-SIGNATURE_VERIFIED:” and “Would you like to enter the initial configuration dialog?” to indicate when the node is ready for user interaction.
pyATS Settings
pyATS is an Open Source, Python framework from Cisco for creating and running automated network tests. Using PyATS, you can write tests that execute and parse CLI output from devices and then to test the execution results, ensuring proper device operation. CML provides a pyats_testbed API that generates a testbed definition for a lab that is ready for use with pyATS tests. Enabling pyATS support and use-in-testbed for a node definition tells CML to include nodes associated with this node definition in the pyATS testbed for a lab, filling in all of the correct device-specific parameters.
Note that pyATS must be enabled if you want to use configuration extraction on nodes associated with this node definition. You can enable pyATS support but leave the Use in Testbed disabled if you’re not planning to use pyATS for anything other than configuration extraction.
Property Name |
Required? |
Description |
|---|---|---|
Enable pyATS |
yes |
If this type of device is supported by pyATS, enable this property. Otherwise, leave it disabled. |
Use in Testbed |
yes |
If enabled, nodes associated with this node definition will show up in exported testbed definitions. If disabled, this device will be omitted from the pyATS testbeds. |
Operating System |
yes |
The name of the operating system according to pyATS. For example, IOSv’s OS type is “ios”. |
Series |
no |
The series of the device. This property is not normally needed for virtual devices, but it could be something like “iosv”. |
Model |
no |
The model of the device. This property is not normally needed for virtual devices, but it could be something like “xrv9k”. |
Username |
no |
The username pyATS should use to log into the device. |
Password |
no |
The password pyATS should use to log into the device. |
Config extract command |
no |
CML uses pyATS to extract configurations from running devices. Therefore, pyATS must be enabled as a pre-requisite for configuration extraction. When you use the Extract Configuration feature of a lab to pull in a node’s current configuration, CML will use this configuration extraction command on nodes associated with this node definition. Note: Not all devices support a single configuration extract command (e.g., Linux has multiple files and subsystems that dictate overall device configuration). If there is a command to capture your device type’s current configuration, specify that command in this property. The output of this command is not processed further and placed as the new Day 0 configuration for the main/first configuration file of the node. If the output is not readily-consumable as the Day 0 configuration, or if the nodes do not actually support Day 0 configuration (see below), you likely do not want this. |
For a complete list of supported devices and their respective OS, series and model settings, consult the official pyATS / Unicon documentation.
Property Inheritance Settings
Property inheritance allows you to define certain properties on multiple levels. Enabling inheritance for a property will allow you to specify a value for the property in an image definition and/or on an individual node associated with this node definition. Disabling inheritance for a property will force nodes to use the value defined in the node definition.
For an inherited property, CML will look first to see whether the property was set on the node itself. If so, CML uses that value. If not, CML checks for a value on the image definition. Finally, if no value was found at the other levels, CML uses the value from the node definition.
As an example, assume that the IOSv node definition specifies RAM of 512 MiB. If you have an image for a particular version of IOSv that requires 768 MiB of RAM, you would create an image definition for that version of IOSv and set the RAM to 768 MiB in the image definition. The image definition will override the RAM setting for any IOSv nodes that use the image. You may also override the RAM value on a node. If you specify 1024MB of RAM on an IOSv node in a lab, that value will apply just for that node, not the value from the image definition or the node definition.
The properties which can use inheritance are:
RAM
CPUs
CPU Limit
Boot Disk Size
Data Disk Size
Configuration Settings
If this device uses a bootstrap configuration that is similar to an existing node definition, select that node type for them here. In the Workbench, when you click the Bootstrap Lab button in the Lab menu, prior to starting a new lab, CML will use the selected value to determine how to generate an appropriate bootstrap configuration for the node, see Bootstrap Configuration Building.
Provisioning Settings
If the device can accept a bootstrap configuration, sometimes called a Day 0 configuration, specify the details for the configuration here. Consult the installation and configuration documentation for your device to learn how its bootstrap configuration works. If enabled, CML will take the bootstrap configuration specified here and convert it to a disk device available within the node’s VM. The IOSv node type is a good example of how to define provisioning in a node definition, but the settings will be very device-specific.
The node’s software should be configured to look for and perform any initial configuration based on this information. The CML software can only provide the configuration files, it cannot force the lab node to use the configuration if it is not programmed to do so. Even in case the configuration is not processed automatically, you may enable provisioning if the running device can access the virtual disk drive and the files help you configure or work with the node more easily.
Multiple configuration files can be added to the configuration disk, distinguished by the path on the configuration disk. You should provide a good default content for each of these files that is useful or required for all nodes. Only text content is supported and will use UNIX-style (LF) end-of-line characters and the UTF-8 encoding to write the content. The maximum size of a configuration file is limited, as is the maximum size of a topology YAML file which may carry this configuration content for all nodes, both to 20MB total.
You can make each of the files editable, which means each individual node may override the default with customized content. You can edit the content on the node’s Config tab in the Workbench. The first editable configuration file is treated as “main” and is the target for configuration extraction function if enabled. Only the editable files specified in the node definition can be placed in the node, additional files are ignored.
You do not need to enable provisioning to take advantage of CML’s node persistence.
Without bootstrap provisioning, the first time a node associated with this node definition
boots, it will boot to its unconfigured state. But once you configure a node in a lab,
that configuration should be preserved with the running node memory state, and/or node disk
state if the node writes configuration to its disk, until the node or lab is wiped.
Some nodes, such as IOS XE require a write CLI command to save the configuration to disk;
in case of IOSv, it saves the configuration back into the configuration disk, not its main
disk. This means that the configuration is not saved when a new Image Definition is created
from an IOSv node.
Docker and IOL nodes can use configuration provisioning, except they do not actually create a disk-like device, but access the files in their own specific manner, i.e. through bind-mounting as defined in the docker configuration within the node definition.
See also Deleting Labs and Starting, Stopping, and Wiping Nodes.
Note
However, if you do not enable provisioning, you will be able to neither provide a bootstrap configuration or extract configuration from nodes created from the node definition. In other words, you will need to manually re-apply the configuration each time you import or wipe the nodes.
Property Name |
Required? |
Description |
|---|---|---|
Enable Provisioning |
no |
If this type of device can access an additional configuration disk, enable this. You will need to then specify one or more files to add to the configuration. |
Media Type |
yes |
The type of configuration disk device, specified through its filesystem type. In order, they select a virtual CD-ROM, FAT16 Flash Drive or an EXT4 Disk. For Docker and IOL and not KVM, use only the RAW option. |
Configuration Disk Volume Name |
no |
Label for the virtual disk device. Most VM nodes require a specific label to recognize the virtual disk as containing the Day 0 configuration for the node. |
Name |
yes |
The file name for each individual configuration file entry. It may be a path inside
a sub-directory, such as |
Editable |
yes |
Allow users to overwrite the content of the configuration for each node. |
Content |
no |
The initial and default content for the configuration file. Defaults to empty, but empty files are not created. |
Node Parameters
KVM nodes can access a set of values normally provided by a physical machine’s BIOS. Most of these values can be set to a custom value in this section. The meaning of these values is outlined in the Node Definition Parameters section.
Each node from this node definition will have these values by default, but it can overwrite each of the values in the node’s Settings tab in the Workbench.
Synchronization of Node Configuration with Node Definition¶
For each node, CML maintains the set of all configuration files as defined in the node definition. It also keeps track of whether you changed any of the editable files for the node. When you make edits, or when you extract configuration from the node, the configuration file is marked as altered. A node definition may change the set or content of its default files, which needs to be reflected on the nodes. This synchronization happens whenever a node is imported from a lab topology file, it is created, started, or wiped, or when any of its configuration files is changed, or when you perform configuration extraction.
During the synchronization:
Compatibility for Node Definitions¶
The allowed values for node definition attributes, as well as the attributes themselves, have changed between releases of CML. This means that node definitions which work in one release need not be usable without modification in another release.
Newer releases of CML may have stricter rules on e.g. the names of node definitions. This should be easy to fix, hence older node definitions will usually work in newer releases with minimal changes if any.
Newer releases can also introduce new optional parameters to allow running of new node types. For example, in the 2.9.0 release, use of Docker-based nodes was introduced, as well as an option to enable Secure Boot for UEFI-based KVM nodes. Older node definitions which did not need these features will not need any changes and continue to work unchanged. However, node definitions which do make use of the new features will not be understood by previous releases of CML and therefore will not work properly even if you remove such attributes from the node definition YAML file.
Creating a New Node Definition¶
Once you have researched the values for your new node definition (or want to try some combination through trial and error), follow this procedure to create the node definition.
Procedure
Navigate to .
In the Node Definitions tab, click Add.
In the Node Definition Editor, fill in the values for your node definition using the information from the above sections and research of any relevant vendor documentation. Initially, all required fields will be marked red as missing until you fill them in.
Click Create at the bottom of the interface to create the definition.
The node definition is created and ready for use in labs. While you can create lab nodes using this node definition, you cannot start them until there is a valid image definition attached to your node definition. See Preparing a Custom Image on how to add one.
Importing a Node Definition¶
Each node definition is stored and can be transferred as a YAML file. If you have a node definition in this format, you can add it to CML by following this procedure.
Procedure
Navigate to .
In the Node Definitions tab, click Import.
In the dialog, click into the Import Definition text field, which opens a browser file selection dialog.
Select the .yaml file with the node definition. The file is imported immediately when the browser dialog is confirmed.
The node definition is imported and ready for use in labs. While you can create lab nodes using this node definition, you cannot start them until there is a valid image definition attached to your node definition. See Preparing a Custom Image on how to add one.
You can also click Go to Node Definition to navigate to the editor interface for the new node definition.
Downloading a Node Definition¶
Each node definition is stored and can be transferred as a YAML file. If you have a node definition in CML, you can download it by following this procedure.
Procedure
Navigate to .
In the Node Definitions tab, choose the node definition you want to download.
In the Node Definition Editor interface, click Download.
The node definition is downloaded using the normal browser function for file downloads. This node definition should be importable in other compatible instances of CML.
Editing a Node Definition¶
You can customize any node definition, for example how configuration extraction works for all nodes that use this node definition. For CML to extract the configuration from a running node, the node definition must provide console-based access, and pyATS must support logging in to the running VM for the node. Most of the node definitions provided with CML support configuration extraction. For the Cisco node definitions provided as part CML, the extracted configuration usually comes from the command:
show run
You can adjust the specific command used to extract configurations, as well as other editable node definition parameters by following this procedure.
Procedure
Navigate to .
Choose the node definition you intend to customize.
If the node definition is marked as read-only in the top-right menu of the node definition editor interface, switch it to writable mode using the switch in the menu.
Edit the editable fields in the node definition according to your preferences.
Click Update at the bottom of the interface to save the changes.
The node definition has been updated. For values which are used when the node is started, mainly the “Linux Native Simulation”, “Interfaces” and “Configuration” sections, only new or wiped lab nodes will make use of the changed values when they are started. All nodes which were already deployed remain set with their previous values.
Removing a Node Definition¶
You can remove any unwanted node definition. Some node definitions however are built into the CML software, and will be re-created each time the CML server services are started. You may rather choose to make such node definitions invisible by editing the corresponding attribute using the procedure above.
Only a node definition which has neither lab nodes nor image definitions associated with it can be removed. To remove a node definition, follow this procedure.
Procedure
Navigate to .
Choose the node definition you intend to remove.
If the node definition is marked as read-only in the top-right menu of the node definition editor interface, switch it to writable mode using the switch in the menu.
Click Delete in the top-right menu of the interface.
The node definition has been removed. Any lab yaml files referencing this node definition will fail to import as a consequence.