Allow the specification of the interdependencies of an option
A config options doesn't stand by itself. There is somewhere another
entity which consumes the value of this option. This could be a binary
like the OpenStack services or another config option. At the same time
an option could be in the role of a consumer of another option. The
interdependency of 1-N config options makes different workflows and
use cases possible. Sometime, the set of config options which are
needed for these use cases cannot often be cumulated under a specific
group. The config options are the interface to the cloud operators
which are interested in workflows and use cases and which services
they have to launch for this. The documentation of this interface could be
improved if we could allow to specify how the interdependencies of
a config option look like.
This enhancement suggest to add two new fields to the "Opt" base class:
1) affects
2) affected_by
An usage example looks like this:
cfg.
The prefixes "bin" and "opt" I used here are just an example and could
be used to enforce checks if
1) a binary uses an option which it is not supposed to ("bin:xxx") or
2) if the reference to another config option is valid ("opt:xxx")
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Markus Zoeller (markus_z)
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
- Markus Zoeller (markus_z)
Related branches
Related bugs
Sprints
Whiteboard
2015-12-02 (markus_z):
Obsolete: We just use "related options:" in the normal help text description of a ConfigOpt declaration.