Our great sponsors
-
ansible-lint
Discontinued Best practices checker for Ansible [Moved to: https://github.com/ansible-community/ansible-lint] (by ansible)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Ansible
Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems. https://docs.ansible.com.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
vscode-ansible
vscode/vscodium extension for providing Ansible auto-completion and integrating quality assurance tools like ansible-lint, ansible syntax check, yamllint, molecule and ansible-test.
In short, we believe the time has come to have a community DNS zone separate to ansible.com, and also to have a project-wide discussion space in the form of a Discourse forum. Crucially though, we don't get to call all the shots - so if you have opinions, or just want to give it a thumbs-up, you can head to the GitHub discussions part 1 & part 2.
Ansible-lint 6.13 introduces a new feature that allows users to utilize a .ansible-lint-ignore file. This file contains skip-rules that are loaded from the ignore file which is adjacent to the config file. Additionally, users can take advantage of the --generate-ignore argument to dump any current violations into an ignore file.
A few updates on what the Networking team is working on: * we are developing some content related to interfaces and ospf * we are working on extending the capabilities of nxos_bgp_global to support the creation of neighbour templates; earlier we could use the module to just apply one that is already created * we are planning to release a filter plugin (ace_popper) which acts on a set of acls facts gathered from a network appliance, and removes ace entries on the basis of some matching criteria
A few updates on what the Networking team is working on: * we are developing some content related to interfaces and ospf * we are working on extending the capabilities of nxos_bgp_global to support the creation of neighbour templates; earlier we could use the module to just apply one that is already created * we are planning to release a filter plugin (ace_popper) which acts on a set of acls facts gathered from a network appliance, and removes ace entries on the basis of some matching criteria
A few updates on what the Networking team is working on: * we are developing some content related to interfaces and ospf * we are working on extending the capabilities of nxos_bgp_global to support the creation of neighbour templates; earlier we could use the module to just apply one that is already created * we are planning to release a filter plugin (ace_popper) which acts on a set of acls facts gathered from a network appliance, and removes ace entries on the basis of some matching criteria
Reach out on Mastodon or see this issue on GitHub.
More than two years ago the Ansible Docs Working Group started discussing the use of semantic markup for Ansible plugin/module documentation. This resulted in a specification that has been implemented as proofs of concept both for ansible-doc and the validate-modules sanity test, as well as for antsibull-docs. From the docs perspective this will improve plugin, module, and now also role documentation a lot, and in particular separate markup from content. (Right now you have to use C(...) and I(...) for values and option names, which stand for 'code-style' and 'italics'.)
More than two years ago the Ansible Docs Working Group started discussing the use of semantic markup for Ansible plugin/module documentation. This resulted in a specification that has been implemented as proofs of concept both for ansible-doc and the validate-modules sanity test, as well as for antsibull-docs. From the docs perspective this will improve plugin, module, and now also role documentation a lot, and in particular separate markup from content. (Right now you have to use C(...) and I(...) for values and option names, which stand for 'code-style' and 'italics'.)
I asked the devtools team and here is their reply: "The telemetry data is sent to the Red Servers and are not publicly available. Though we have documented the usage data that we gather here."