Is ConfD suitable for Configuration Management

ConfD seems suitable for a device supporting a variety of interfaces for configuration and having its configuration done w.r.t YANG models. What about using it for configuration management of a variety of remote devices/services? e.g remote services having configuration in ConfD side and configuration is done via ConfD management application interfaces. Is it a suitable scenario for ConfD usage?

From the ConfD Kick Start Guide:

1 Like

I would add that managing a network of many devices poses some additional challenges that ConfD might not be well equipped to deal with, such as:

  • ConfD assumes that once a transaction passes through the validation and prepare stages, nothing can really go wrong; any failures later on are assumed to be very exceptional and ConfD does not have built-in mechanisms to deal with them. With multiple managed devices distributed over unreliable network such exceptions might become considerably more common.

  • When ConfD is deployed to manage interfaces of one router chassis, it is safe to assume that no one changes interfaces’ configuration directly, not through ConfD; so ConfD (and especially its CDB, if it is in use) is always the single source of truth. This assumption might be too far from reality when you are managing multiple network devices, and again, ConfD does not have good built-in mechanisms to resolve such conflicts.

  • Transactions and in particular subsequent managed objects’ subscriptions processing are typically fast, pretty much immediate. You can accommodate slower objects by fine-tuning timeout settings, but this works only up to a point. When you manage multiple network devices with different speeds, different RTTs, you might need other mechanisms to deal with the problem without losing slower devices on one hand and making your system unresponsive on the other hand.

And there may be more.

2 Likes

Very good points from practical point of view, thank you. If we focus on applications / services, is 1 ConfD CDB suitable for different application configurations where these applications do have really distinct configurations. Let’s say we have two different applications with very different configurations. Is it still suitable to use one CDB for managing these configurations? In the image that cohult shared above, remote applications are same applications using same configuration set or can they be very different applications with different configurations?

Thanks for detailed explanation. I’ve already seen similar diagram in ConfD user guide. However I want to understand the applicability in practice for remote applications / services having distinct configurations.

YANG models become the schema, so you can have a vastly different configuration in each YANG model, parts of YANG models, or set of YANG models.

The application then typically subscribes to configuration changes based on a path that it provides ConfD with. That path can point to any part/leaf/subtree of the CDB schema that is made up of a YANG model, part of a YANG model, or set of YANG models.

See “The YANG 1.1 Data Modeling Language” RFC and ConfD UG chapter “CDB subscriptions”

1 Like