Chapter 8. Configuration Meta-Data

In ConfD, meta-data can be associated with configuration data nodes. The meta-data is stored as attributes on data nodes in the configuration datastore. Having meta-data is optional, and requires support from the datastore implementation. CDB (see Chapter 5, CDB - The ConfD XML Database fully supports meta-data attributes, but if an external data provider (see Chapter 7, The external database API is used for configuration data, it needs to explicitly support meta-data attributes.

There are three meta-data attributes in ConfD, annotation, tag, and inactive. Each of these is discussed in the following sections.

To enable meta-data attributes, /confdConfig/enableAttributes in confd.conf (see confd.conf(5)) must be set to true.

Any configuration data node can have at most one annotation attribute. An annotation is an arbitrary string which acts a comment for the node.

In the CLI, an annotation is set with the annotate command, and displayed as a comment. See Section 16.14, “Annotations and tags” for details.

admin@host% annotate interface eth0 "mgmt interface"

admin@host% show interface
/* mgmt interface */
interface eth0 {
  ...
}
      

In NETCONF, an annotation is created and display as an XML attribute, see Section 15.15, “Meta-data in Attributes” for details.

Annotations are not visible in the CDB API for CDB subscribers.

Any configuration data node can have a set of tags associated with it. Tags are set by the user for data organization and filtering purposes.

In the CLI, tags are administered with the tag command, and displayed as a comment with special syntax. It is also possible to filter the configuration based on how it is tagged. See Section 16.14, “Annotations and tags” for details.

In NETCONF, a tag is created and display as an XML attribute, see Section 15.15, “Meta-data in Attributes” for details. Standard XPath filtering can be used to filter the configuration based on how it is tagged.

Tags are not visible in the CDB API for CDB subscribers.

Any existing, deletable data node can be marked as inactive. This has the same effect as deleting the node, except that it is still kept in the configuration data store, marked as being inactive.

To enable support for inactive nodes, /confdConfig/enableInactive in confd.conf (see confd.conf(5)) must be set to true. All configuration data providers must support the inactive attribute.

In the CLI, the command deactivate makes a node inactive, and the command activate activates an inactive node. See See Section 16.15, “Activate and Deactivate” for details.

In NETCONF, a separate capability is used by the server to announce that it supports inactive nodes. Clients must use special parameters to tell the server that they understand the inactive attribute. See Section 15.12, “Inactive Capability” for details.

Inactive nodes are not visible in the CDB API for CDB subscribers. If a node is inactivated, a CDB subscriber will see the node as being deleted, and when it is activated, the CDB subscriber will see it as being created.

Inactive nodes are not visible in validation code (see Chapter 9, Semantic validation). Validation constraints defined in the data model (e.g. max-elements or must) do not take inactive nodes into account.

Since data providers must support the inactive attribute, all hooks and transforms (see Chapter 10, Transformations, Hooks, Hidden Data and Symlinks) will see the inactive nodes being marked as inactive, and must be explicitly coded to handle this attribute.

admin@host% deactivate interface eth0

admin@host% show interface
inactive: interface eth-0 {
  ...
}