Associated PR: <link to GH PR in ansible/proposals if PR was submitted>
Estimated time to implement: <X days, weeks, etc.>
Motivation
This is a topic (holistic view on facts) I wanted to discuss at AnsibleFest SF, but since a redesign like this touches both the API as well as the user interface, I am not sure doing it as part of a public proposal is a good way to make a concise and well-designed implementation.
The problem is that without a good consensus on how Ansible ideally would work, every small improvement added may make that end-goal harder to reach, so a direction is important.
TBD
Problems
What problems exist that this proposal will solve?
A single namespace where everything lives (facts, inventory, registered vars, ...)
Changes to how facts work have been proposed before, but lacked a holistic view
Using reserved namespaces enables new uses (like module/categoy-specific variables)
Solution proposal
TBD
Dependencies (optional)
Explain any dependencies. This section is optional but could be helpful.
Dependency #1
Dependency #2
Testing (optional)
Does / should this require testing, and if so, how? Describe here. This section is optional but could be helpful.
Documentation (optional)
Does / should this require documentation? If so, describe here. This section is optional but could be helpful.
Anything else?
If you'd like to add anything else beyond the above required and optional sections, you are welcome to do so.
Proposal: Redesign facts and hostvars namespacing
Author: Dag Wieers @dagwieers Date: 2017-10-18
Motivation
This is a topic (holistic view on facts) I wanted to discuss at AnsibleFest SF, but since a redesign like this touches both the API as well as the user interface, I am not sure doing it as part of a public proposal is a good way to make a concise and well-designed implementation.
The problem is that without a good consensus on how Ansible ideally would work, every small improvement added may make that end-goal harder to reach, so a direction is important.
TBD
Problems
What problems exist that this proposal will solve?
Solution proposal
Dependencies (optional)
Explain any dependencies. This section is optional but could be helpful.
Testing (optional)
Does / should this require testing, and if so, how? Describe here. This section is optional but could be helpful.
Documentation (optional)
Does / should this require documentation? If so, describe here. This section is optional but could be helpful.
Anything else?
If you'd like to add anything else beyond the above required and optional sections, you are welcome to do so.