707458cc8c
Change: Our handling of NetBSD virtualization facts led to facts that were just plain incorrect. One example is reporting Xen even when the system is running on something completely different (like KVM). As stated by the reporter of #69352, NetBSD has a better sysctl setting to use for this information, machdep.hypervisor. This PR does the following: - Try to use machdep.hypervisor sysctl value if the other sysctl values we check don't end up with enough information to be useful - Only look for /dev/xencons and assume Xen if nothing else works (Really this should probably return 'unknown' since the file exists on non-Xen systems and is not very useful). - Add a few more patterns (Xen matches and also Hyper-V) to VirtualSysctlDetectionMixin#detect_virt_product. This change is slightly breaking: - If the first two attempts at using sysctl worked before, (machdep.dmi.system-product and machdep.dmi.system-vendor), they will continue to work. - For cases when those values didn't work, previously the existence of /dev/xencons was checked, and if found, we reported 'xen' (even on non-Xen systems when the file existed). After this PR, we try the machdep.hypervisor sysctl key before still falling back to /dev/xencons. This means that in some cases, we might go from (wrongly) saying "xen" to giving a more accurate value such as "kvm" or "Hyper-V". Test Plan: - Tested with local NetBSD VM and got 'kvm' instead of 'xen' back. Tickets: - Fixes #69352 Signed-off-by: Rick Elrod <rick@elrod.me> |
||
|---|---|---|
| .. | ||
| _extensions | ||
| _static | ||
| _themes/sphinx_rtd_theme | ||
| js/ansible | ||
| rst | ||
| .gitignore | ||
| .nojekyll | ||
| ansible_2_5.inv | ||
| ansible_2_6.inv | ||
| ansible_2_7.inv | ||
| ansible_2_8.inv | ||
| ansible_2_9.inv | ||
| jinja2.inv | ||
| keyword_desc.yml | ||
| Makefile | ||
| Makefile.sphinx | ||
| modules.js | ||
| python2.inv | ||
| python3.inv | ||
| README.md | ||
| requirements.txt | ||
| variables.dot | ||
Ansible documentation
This project hosts the source behind docs.ansible.com.
To create clear, concise, and consistent contributions to Ansible documentation, please refer to the following information.
Contributions
Contributions to the documentation are welcome.
The Ansible community produces guidance on contributions, building documentation, and submitting pull requests, which you can find in Contributing to the Ansible Documentation.
You can also join the Docs Working Group.
Ansible style guide
Ansible documentation is written in ReStructuredText(RST). The Ansible style guide provides linguistic direction and technical guidelines for working with reStructuredText, in addition to other resources.
Tools
The Ansible community uses a range of tools and programs for working with Ansible documentation. Learn more about Other Tools and Programs in the Ansible Community Guide.
GitHub
Ansible documentation is hosted on the Ansible GitHub project. For GitHub workflows and other information, see the GitHub Guides.