Of using eos_cli_config_gen native keys when running eos_designs¶
Context¶
For several AVD major versions, it has been possible to use variables from the eos_cli_config_gen data model in conjunction with variables from the eos_designs data model. When the eos_designs
role runs, the eos_cli_config_gen keys are ignored but they will be read later by the eos_cli_config_gen role.
While this behavior could serve as a good escape hatch, it has led to confusion among users. Especially when new features introduced in eos_designs ended up shadowing the inputs intended for eos_cli_config_gen,
sometimes leading to configuration changes after a minor releases upgrade. This behavior is well documented and described in the eos_designs how-to on
custom_structured_configuration which is the recommended way of
using eos_cli_config_gen variables within eos_designs. However the direct usage of eos_cli_config_gen variables still works.
Changes¶
AVD 5.6¶
Starting AVD 5.6, the eos_designs role emits deprecation warning identifying the native eos_cli_config_gen keys being used.
The solutions to address such warning should be in order of priority:
- Look at the newest models introduced in
eos_designsand use the relevant one. Many new features are added in each minor release to cover more and more ineos_designs. - If 1. is not possible, open an issue on Github describing your need and usecase and use custom structured configuration.
Example¶
The following eos_cli_config_gen key:
will emit a warning when read by eos_designs.
Following 1, it should be changed to
Following the less preferred option 2, it could have been changed to:
---
# assuming a default custom strutcured configuration prefix
# this will not warn
custom_structured_configuration_dns_domain: my.awesome.domain.local
Future¶
Starting AVD 6.0, the nominal behavior of eos_designs will be to ignore eos_cli_config_gen native keys.
Please reach out to the maintainer team via Github discussions if you have any questions or concerns.