Reserved Fields Consistency Validator
Overview
The "Reserved Fields Consistency Validator" feature is designed to ensure that specific fields within the YAML descriptor of an entity remain unmodified from their original values. This documentation provides an overview of how to configure and utilize the Reserved Fields feature effectively.
Configuration
To configure the Reserved Fields Consistency Validator feature, you have two parts to consider: global and local fields.
Global Fields
In the global section of the configuration, you can enable the Consistency Validator feature for the fields
metadata.name
and kind
of the entities. This means that the validator will work for all kinds of entities.
You can set the name and kind fields to either true or false to enable or disable the validator for each field,
respectively.
Example:
mesh:
reservedFields:
global:
name: <true/false>
kind: <true/false>
Local Fields
In the local section of the configuration, you can define specific reserved fields for different entity kinds. This allows you to customize reserved fields based on the type of entities you are working with. You can specify the entity kind and its paths
Example:
mesh:
reservedFields:
local:
myKind:
- 'path.one'
- 'path.two'
anotherKind:
- 'path.one'
You can add more entries to define reserved fields for other kinds as needed.
You cannot enable the validator feature for metadata.name
and kind
with respect to different kinds;
they can only be set at the global level.
Similarly, you can specify kind-path values only for local fields.
Example configuration:
mesh:
reservedFields:
global:
name: true
kind: false
local:
system:
- 'spec.mesh.email'
component:
- 'spec.mesh.email'
- 'spec.domain'
In this example, the validator is enabled for the metadata.name
field of all kinds.
It is also enabled for the spec.mesh.email
field of entities with the System
and Component
kinds,
and for the field spec.domain
of entities with the Component
kind.
With this configuration, the Reserved Fields Consistency Validator will ensure that the specified fields remain unmodified for the entities of the specified kinds. If any reserved field are modified, the system will detect the change during the next entity refresh, and the entity will display an error in the UI, telling you to restore the original fields' names.
To resolve this issue, you must edit the entity yaml descriptor and return the reserved fields to their previous values. After restoring the fields you can trigger a refresh, or you can wait for the scheduled refresh to happen automatically. After the system detects that the original entity has been restored, it will delete all invalid duplicates
You can see the consistency status of an entity in its metadata.annotations
field if you inspect the entity.
Once an entity has been marked an invalid, it will forever continue to be invalid. If you delete the original entity after its name or kind changed and a duplicate was generated, you can still modify restore the reserved fields value to their previous ones, and the original entity will be generated once again.
Disabled entities and kinds
The Consistency Validator feature is selectively disabled for certain entities and kinds to ensure accurate processing. Here are the exceptions:
Entities Originating from url
The Consistency Validator is disabled for entities that originate from a location with type url
.
This exclusion is to accommodate entities that are loaded externally, such as those obtained from a file or ingested
through protocols like AD (Active Directory) or LDAP (Lightweight Directory Access Protocol).
Disabled Kinds
The feature is disabled for entities with the following kinds:
Location
User
Hierarchy
HierarchyClass
Entities of these kinds will not undergo Consistency Validator checks during processing. The exclusion is intentional to suit specific use cases where validator verification is not applicable or relevant.