Summary

This idea came up in the Documentation Working group meeting. Based on the docs survey from the beginning of this year, our readers are looking for more examples.

One specific area mentioned was more and better templating examples. So the idea came about that maybe we can create an area for community-contributed examples to expand on our existing documentation. This could either be on docs.ansible.com/ansible, or within a github repo. The docsite would in theory be more 'findable', but we wanted to open this up to community discussion to see if it's something people would want to contribute to, and how best to make this easy and yet verifiable that the examples work.

This is the docs survey feedback for the specific template example request - ansible/ansible#75507

There could be three useful types of image imho:

• ansible installed
• systemd installed
• ansible & systemd installed

Currently I'm maintaining https://github.com/aminvakil/docker-os-systemd/ (includes systemd) & https://github.com/aminvakil/docker-ansible (includes systemd and ansible) for repositories I need molecule to test on to, but it would be really great if there was an official docker images where users could use them, ansible-molecule can put its link on its documentations and so on.

Summary

Per my discussions prior to the Matrix adoption, we need to decide how to give out accounts on our homeserver. I want to give these out (we already pay for them) so we want to make this easy - but we have to treat it the same as we would a project email address, it confers some reputation and responsibility on the account holder.

So, we need a lightweight way assign these to people we trust. I want to build a proper solution to this in the long term, but for now I suggest we use a simple "vouch" system:

• Account is requested by a user
  • Where should this be? A GitHub issue? It needs to be auditable
• Request is given +1 by existing community members
  • How many +1s? I'm thinking 2...
  • Who can +1? Steering committee, IRC ops, and other ansible.im account holders (so that we can spider out as a web-of-trust)?
• Account is created and handed over by the Matrix admins (myself, @gundalow, and @dmsimard currently)

I'll be looking into making that more automatic later on (GNOME are working on something similar, we can likely collaborate) but this will get us started.

Thoughts very welcome!

Additional Information

No response

TLDR: we voted that we will move to Libera.chat (see #19 (comment) for more details).

(original post below:)

Summary

Since the current Freenode drama seems to be intensifying (like multiple global messages warning about user data being given into other hands), we should discuss whether we want to continue to meet on Freenode, or move somewhere else.

Edit: in case you missed the drama, here are some links:

• https://fuchsnet.ch/freenode-resign-letter.txt, http://kline.sh/, ...
• https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
• https://lwn.net/Articles/856543/
• https://freenode.net/people vs https://web.archive.org/web/20210423231451/https://freenode.net/people

Since another chance to move the nios content from community.general to infoblox.nios_modules passed, and it is annoying for both users and maintainers that there are two copies of them around, I suggest we deprecate the nios content in community.general (for removal in community.general 5.0.0, i.e. in a year) where the deprecation message says to use the corresponding content from infoblox.nios_modules instead. If infoblox.nios_modules is included in Ansible before the removal happens, we can still replace the plugins with redirects, but if not, at least the users know where to find undeprecated versions of them.

The drawback (if infoblox.nios_modules is not eventually included in Ansible) is that the short names will be 'burned'.

Summary

There are a lot of modules and plugins in community.general (and I guess also community.network, and probably in some more collections) which are basically orphaned, partially/potentially broken (we don't know because we don't know if anyone actually uses them), and we have no idea what to do with them.

An example is the serverless module in community.general (ansible-collections/community.general#2558).

I think we need a process to mark such modules and plugins as orphaned, and if nobody is interested in some time, deprecate and finally remove them. Maybe orphaning it for one major version (i.e. mark it as orphaned, mention that in the changelog), then deprecate it, and two major versions later remove it in case nobody mentioned any interest in the module.

(For marking it as orphaned we can use ansible/proposals#68, though that implementation seems to be still in flux. It should be available for ansible-core 2.12 tough.)

During the big content migration from ansible/ansible, quite a few inventory and vault scripts were moved to community.general; see https://github.com/ansible-collections/community.general/tree/main/scripts/inventory and https://github.com/ansible-collections/community.general/tree/main/scripts/vault.

Since inventory and vault scripts are not 1st or even 2nd class citizens of collections, are not related to code in the collection (the only exception being the infoblox script, but the content it uses is now deprecated), have no tests (only sanity tests run on them), and in case of inventory scripts are even discouraged in favor of inventory plugins (which are 1st class citizens of collections), I want to propose the idea to move them to a separate repository (which is not a collection repository).

In most cases, it seems that users download or copy these scripts to where they use them anyway, instead of running them from community.general directly, so IMO there's no reason they should be part of community.general. The only advantage of having them in a collection that's included in Ansible is that if you install Ansible, they are around somewhere in your filesystem (but you have to find them first before you can use them :) ).

What do you think?

Summary

This topic is about ansible-collections/overview#187. The vote referenced in there is from https://meetbot.fedoraproject.org/ansible-community/2021-02-03/ansible_community_meeting.2021-02-03-19.00.html.

When someone opens an issue I often miss the information what version of the collection is used. The one that comes with ansible or a different version installed via galaxy? Maybe this question should be part of the template.

What do you think?

context: ansible-community/collection_bot#29 (comment)

Summary

This issue contains high-level information about the inclusion process of each candidate. Feel free to edit as things progress.

2021-10-12
Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion.
Ansible 5.0.0 Roadmap

Already accepted collections

• community.dns
• comunity.ciscosmb
• infoblox.nios_modules
• netapp.storagegrid
• cloud.common

1. cisco.dnac - no reviews yet

2. equnix.metal - unresolved issues

• There was some activity in the inclusion discussion, but nothing to review yet since things are not in the main branch yet. This is still true as of 2021-10-15.
• @felixfontein reviewed the candidate, waiting for maintainer feedback.

3. vmware.vmware_rest - unresolved issues

• @tadeboro reviewed the candidate, no open issues (needs a new release and cloud.common needs to make into Ansible 5).
• @felixfontein reviewed the candidate, waiting for maintainer feedback (there are still some unresolved issues present).

4. trendmicro.deepsec - unresolved issues

• @tadeboro reviewed the candidate, waiting for the maintainer feedback (there are still some unresolved issues present).

5. networktocode.nautobot - needs another review

• @tadeboro reviewed the candidate.

6. cisco.ise - needs action from reviever

• @Andersson007 reviewed the candidate, waiting for maintainer feedback.
• @tadeboro reviewed the candidate.

7. dellemc.unity - unresolved issues

• @tadeboro reviewed the candidate, waiting for maintainer feedback.

8. dellemc.powerflex - unresolved issues

• @tadeboro reviewed the candidate, waiting for maintainer feedback.

Summary

The idea was originally said by @mattclay

We should replace "Changes Impacting collection contributors and maintainers" Issue 45 with a dedicated repository (for example, we could create ansible-collections/changes_impacting_maintainers).

Issue: Now it's a problem to find anything in the issue (even recent announcements) as it's hard to unfold 460 hidden items to find important information. Things get lost there quickly...

Solution:

• Using a repository instead.
• Announcements will be done as separate issues.

Benefits:

• Possibility to ask questions in issues, discuss things, add clarifications.
• Easy tracking maintainers who are subscribed / not subscribed (to remind them if we see that they don't consider the changes in their collections
• Easy linking related PRs / issues in collection repos (now this causes a need to unfold 460 hidden items in the single issue).

Questions that can be asked:

1. What about changes that aren't (only) about collections?

• Currently Issue 45 is in ansible-collections/overview.
• At least recently I can see things that relate to collections only. I believe we should keep the focus.
• If there's a need for Issue of broader scope than Changes Impacting, it would already exist.
• We have Bullhorn. We recommend maintainers to subscribe to it. As far as I noticed, important changes of different areas (and global ones) are announced via the newsletter.
• Bullhorn + the repo is a good combination for collection contributors and maintainers. For others, Bullhorn + corresponding repos.

Conclusion:
I suggest creating the repo ansible-collections/changes_impacting_maintainers that will keep focusing on collection contributors and maintainers and close Issue 45.

Summary

Context: Offtopic chat is hugely important in building a cohesive social group, and we should be thinking clearly about how to encourage it, rather than letting it happen by accident.

Currently offtopic / chat is generally held in #community:ansible.im / #ansible-community. This has arisen organically, which is fine, but we have an opportunity to revisit this due to 2 converging things:

1. The upcoming Summit-as-part-of-Fest is likely to bring a lot of new members (even if temporarily) and it feels wrong to swamp the purpose of #community with people getting to know us. A place for new folks to get oriented, be signposted to the right place for their topic (whether the support room, a working group room, etc) or just to talk about our weekends seems right.
2. With the adoption of Matrix, we also inherit the 300+ user #ansible:matrix.org room, and that currently represents a fragmented community, as user support is happening there and in #users:ansible.im / #ansible. Forcing them all to abandon that room destroys a community that has existed for 4+ years.

Instead I propose we make #ansible:matrix.org into the "welcome" room, add an IRC bridge to #ansible-welcome, and make that our "landing page". This will return #community:ansible.im to it's intended purpose as the working group for improving the community, although I'm sure we'll still chat there too :)

This is a short overview of the inclusion candidates. Feel free to update the issue if I made a mistake or add a comment below if you would like to discuss something.

Ready for inclusion

1. dellemc.enterprise_sonic
2. hpe.nimble
3. netapp.azure
4. netapp.cloudmanager

Almost ready

1. netapp.um_info - we need to decide if the _info module renaming can be delayed a bit

Not ready

1. equinix.metal - missing release policy documentation, CI does not run against ansible-core-2.11
2. infoblox.nios_modules - failed to apply some fixes that are already part of community.general, there is a general lack of maintenance.
3. cisco.dnac - content does not follow standard development practices.

While reviewing the netapp.cloudmanager Ansible Collection, I learned that some of the collections do not follow semantic versioning. The collection in question has more information about versioning in the pinned issue.

I described some of the problems using the custom versioning scheme brings in my review comment.

Right now, if someone would ask me "does collection that does not follow semantic versioning still qualifies for inclusion in community Ansible package", I would say no. But I would like to hear from other people what they think about this topic.

Summary

The 2.0 release of community.kubernetes will contain only redirects to kubernetes.core 2.0 with the intention of ultimately retiring the community.kubernetes name. We would like to figure out a reasonable schedule for deprecating and removing community.kubernetes. See #21 (comment) for some more information.

Summary

Right now, the development conventions section in collection requirements use general best practices as its base. And while those general rules do offer a good baseline, parts of the Ansible ecosystem developed their own set of best practices when developing Ansible content.

For example, resource modules have their own set of conventions that contradict the general best practices in certain places.

Maybe we should expand the best practices section and add some specialized subsections for things like network collections?

Summary

From the Ansible Roadmap:
2021-11-08 last chance for major version bump
2021-11-09 Ansible 5.0.0 beta1 - feature freeze
2021-11-16 Ansible 5.0.0 beta2
2021-11-23 Ansible 5.0.0 rc1
2021-11-30 Ansible 5.0.0 release
2022-12-21 Ansible 5.1.0 release (proposal in #45)
2022-01-04 Ansible 5.1.0 release (current, if proposal in #45 is not accepted)

The next planned community.general release is 3.8.0 on October 12th (this is the regular three week schedule). My proposal is to make this the last 3.x.0 minor release, and do the 4.0.0 release three weeks after that, on November 2nd (and potentially the first 3.8.1 bugfix release). That would be

2021-10-12 c.g 3.8.0
2021-11-02 c.g 4.0.0 (major release!)
2021-11-02 c.g 3.8.1 (if neccessary)
2021-11-23 c.g 4.1.0
2021-11-23 c.g 3.8.2 (if neccessary)
2021-12-21 c.g 4.2.0
2021-12-21 c.g 3.8.3 (if neccessary)
...

with the regular three weeks interval. This would:

1. Have 4.0.0 released one week before the deadline (and if we need 1-2 days more, it's still in time);
2. Have 4.1.0 released so it can go into Ansible 5.0.0
3. Have 4.2.0 released so it can go into Ansible 5.1.0

Additional Information

No response

Summary

As pointed out by @ganeshrn in #33 (comment), the current meeting times make it hard for people from some parts of the world to participate.

This issue should be used to collect some ideas on how to improve this, so that we can discuss these and possibly implement some of them.

(Related issue: we have too many things to discuss in meetings and too little time for everything. Earlier suggestions were to move more discussions to issues, and have the meeting more for votes. That obviously also would help in this case, and similarly might other ideas discussed here.)

Collection requirements and checklist: add clarifications about info / facts modules submitted for inclusion

ansible-collections/overview#169

In essence:

• info / facts modules in collections must be named as <something>_info / <something>_facts
• modules do not allow to query information using special state option values
• info / facts modules must support check_mode

Summary

With AnsibleFest approaching we want to start planning the next Contributors Summit

• Tuesday 28th September
  • self-paced learning (Katacoda/Instruct)
  • Open office hours
  • Hackathon?
• Wednesday & Thursday: Ansible Fest
• Friday 1st October: Interactive Contributor Summit (usual discussion)

Hackmd will be created soon.

Questions

1. What other things can we do on Tuesday, given this maybe the first opportunity a lot of attendees have to interact with the community
2. How can we identify easyfix & good first issue topics
3. What existing Collection tidyup activities could be good for people to do (such as ignore.txt)
4. If we are to do Sprints, what should they be on?

Summary

Community Ansible documentation wants to add semantic markup within the module/plugin DOCUMENTATION strings. This gives us improved flexibility on how we display this information.

Additional Information

Background
This started with a general dissatisfaction on how some of the module options and parameters are displayed on docs.ansible.com (what is bold, what is italics, monospace, etc) and the inherent inflexibility of our current markup options.

Primary goal - To improve the visual aid that helps readers determine what the differences.​
Secondary goal - Do this in such a way that we do not have to touch the code in ansible/ansible again if we decide we need to display this information in a different way.
Solution - Introduce a light level of semantic markup, where the developer 'marks' the content for what it is (module, value, option, etc) instead of how it should display (bold, italics, monospace, etc). This leaves the visual aspect to separate code we can update at will.

Specific changes
The community decided on the following additions:

• O(key) and O(key=value) for option names, with or without values
• V(value) for standalone option values
• E(env_var) for environment variables
• P(FQCN#plugintype) for plugin references

Existing markup macros will remain, including:

• M(FQCN) for module references
• C(code) for other monospace text such as linux commands
• B(bold_text) and I(italic_text) for other words or phrases an author wants to emphasize

These added macros may impact other projects, such as Galaxy-ng/Automation Hub, ansible-navigator, possibly the vscode plugin, and the collection_prep script used by some collections to generate local rst docs files.

For more complete details and WIP PRs, see ansible/ansible#75054.

The question whether new content should be added to community.general (and community.network) has been discussed already a while in October/November 2020, before we postponed it to discuss the guidelines for including new collections into Ansible.

This post should sum up and link to (most of) the discussions we had.

October 22nd (ansible/community#539 (comment))

Should we accept new content (plugins, modules) from companies for their products in community.general/community.network? Or should we force them to create their own collection?

So far we did force them if they wanted to submit a group of modules/plugins. What should we do if they start with only one? (Exampe: ansible-collections/community.general#772)

First discussion at https://meetbot.fedoraproject.org/ansible-community/2020-10-28/ansible_community_meeting.2020-10-28-18.02.html

November 4th (ansible/community#539 (comment))

Possible non-binding poll for next time [pick all that you are okay with]: (A) No new content in c.g (we'll work out some other place to put new content) (B) new content in c.g limited to things that aren't likely to have more than a few (<5) new pieces of content. (C) new content only in areas which already exist in c.g (D) allow any new content that can pass review into c.g

November 4th (ansible/community#539 (comment))

https://meetbot.fedoraproject.org/ansible-community/2020-11-04/ansible_community_meeting.2020-11-04-18.02.html:

• for larger set of new modules/plugins, we ask submitter to create their own collection (felixfontein, 18:09:29)
• ansible-collections/community.general#772, | closed, created 2020-08-13T14:47:00Z by st8f: Yandex.Cloud inventory plugin

November 11th (ansible/community#539 (comment))

Should we accept new content in community.general (and community.network I guess)? Possible scenarios to vote on:

1. Absolutely no new content. Only features to existing modules/plugins and bugfixes are allowed.
2. New content only in areas that already have content, i.e. new GitLab modules would be accepted, new RandomNewCodeHoster modules would not be accepted.
3. Accept content from new areas, but only if it is not likely there will be more than a few (< 5) new pieces of content, and if they can give a convincing argument why the new content should really be in community.general and not in a new collection or community.beta|incubator|... (Content for existing areas is accepted if it passes review.)
4. Accept content from new areas, but only if it is not likely there will be more than a few (< 5) new pieces of content. (Module and _info module for a new ticketing or vault service would be ok. Modules/plugins for a new cloud provider would not be.) (Content for existing areas is accepted if it passes review.)
5. Allow all new content that passes review.

(Right now, we are somewhere between 3 and 5.)

November 11th (ansible/community#539 (comment))

Meeting discussions: discussion will be continued; general gist: options i-iii are of interest; making creation of new collections including CI simpler is something that should be high priority (https://meetbot.fedoraproject.org/ansible-community/2020-11-11/ansible_community_meeting.2020-11-11-19.00.html)

This is a place for non-Reddit users to provide feedback and ask questions on the proposal of moving Community Galaxy (galaxy.ansible.com) to the GalaxyNG codebase.

If you have any feedback on the survey, please leave it here.

• For details see Reddit post
• Survey Estimated 2 mins to complete

• Initial Reddit post
• Draft survey
• Survey on Reddit
• Survey on https://galaxy.ansible.com/
• Survey on docs.ansible.com ansible/ansible#74889

Summary

So, while searching for reference to freenode to remove, I stumbled on a few repositories that should be IMHO archived:

• https://github.com/ansible/ansible-container-examples This one is marked as deprecated, but not set as readonly.
• https://github.com/ansible/ansible-lockdown this one likely moved to https://github.com/ansible-lockdown, as pointed by gundalow. The url listed redirect to a new website, and this repo predate RHEL 8 release.
• https://github.com/ansible/zuul-test-repo not sure if it is still used. I would love to have it at least updated so it doesn't pollute search result on github
• https://github.com/ansible/ansible-azp same as zuul-test-repo. If no longer used, I guess it can be removed. Archived
• https://github.com/ansible/ansible-bare Not sure about this one, maybe it can be archived. deleted by gundalow
• https://github.com/ansible/training-content not touched since 7 years
• https://github.com/ansible/python-social-auth not tested on any non EOL python version, no commit since 2015
• https://github.com/ansible/ansiconv not touched since years (2014), likely still python 2 code
• https://github.com/ansible/django-template ansible container example, so likely need to be archived

Then we also have:

• https://github.com/ansible/azure-testing seems a test repo, should likely be archived
• https://github.com/ansible/ansible-container-demo ansible-container is deprecated, so this should be archived too
• https://github.com/ansible/ansible-runner-aio 1 commit, likely can be archived
• https://github.com/ansible/ansible-runner-zeromq 2 commits
• https://github.com/ansible/ansible-runner-http 4 commits

Summary

Ansible 5 is scheduled to be released on 2021-11-30.

We are currently up to Ansible 4.7.0 (released Oct 13th) and with the pace of a maintenance release every three weeks we will have:

• Ansible 4.8.0 on 2021-11-02
• Ansible 4.9.0 on 2021-11-23
• and then, should we decide in the affirmative, Ansible 4.10.0 on 2021-12-14.

We've so far stopped running maintenance releases after the following major version came out but it may be appropriate or desired by the community to do a release of 4.10.0.

In any case, we would like to announce the last version in advance and need to decide whether that will be 4.9.0 or 4.10.0.

Summary

SUMMARY

Hello,
As asked, reposting this from ansible-collections/overview#177

Not to be nitpicking, but when installing the metapackage ansible 3.4.0, I was surprised by the size the docker image I built took.

To be more specific, create a virtualenv and install ansible with pip3 install --no-cache-dir ansible==3.4.0
Then :

$ cd <venv>
$ du -sh 
484M    .

$ cd lib/python3.*/site-packages/ansible_collections
$ du -sh
400M    .

# list all "tests" directories under collections and return their disk size
$ find . -name "tests" -type d -print0 | xargs -0 du -sh --total
(...)
122M    total

That was at first glance.

While I understand the need of the unit and integration tests, they can become heavy in disk space consumption.
Maybe I missed something, but is there a requirement to have them shipped in the release builds ?

ISSUE TYPE

• Enhancement

Additional Information

No response

Something that coexists with ansible-test sanity, and can check more conditions from https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst, for example ansible/ansible#74558 (Error if non-standard dirs exist under plugins/).

Advantage over having that (configurable in some way) in ansible-test: you don't need to use ignore.txt entries for older ansible-test versions if you are using a new plugin type that is introduced in a new ansible-core version; instead, just upgrade the linter.

Disadvantage: yet another tool to use, and someone has to write and maintain it.

RHEL6 (which uses python-2.6 as its base python) went EOL at the end of November, 2020. That leaves no active RHEL and no active Ubuntu LTS releases which are based on python-2.6.

ansible-collections/overview#165

Open questions:

1. Does every agenda entry need an issue here?
2. a) Should the issue be mentioned in ansible/community#539?
   b) Or should that issue be locked and only used for announcements / meeting minutes?
   * In that case, a list of potential topics should be posted before the meeting in the agenda?
   * Or should the meeting work with the open issues here (we can use labels to organize them better for that)?

Today we were discussing ansible-collections/community.general#2213, which proposes to add a module disk_info to community.general which allows to retrieve basic information on disks/filesystems (free space, used space, capacity, inodes, ...).

While similar information is provided by the setup module, this module provides the information in a different way that is potentially easier to use. (See ansible-collections/community.general#2213 (comment) for one way how to convert from setup output to something similar as this module's output.)

We had a quick vote on whether to include this, and we had very few -1, a lot of 0s, and a few +1/+0.5s. So this is something we have to discuss again :-)

Possible outcomes:

1. Merge this module, since it makes it easier to obtain information in this format (big Q: how useful is the format returned by the module to the average user?).
2. Improve documentation on how to solve such problems with filters.
3. Add more filters which make such conversions easier (a groupby-like filter which groups a list of dictionaries by an attribute, example).
4. Ask the authors to rewrite the module to only return information on one disk/filesystem, so the results can be used even easier.
5. More than one of the above.
6. Reject it as a duplicate (and none of the above).
7. Something else?

Summary

Whilst I have been researching, discussing & testing this for a while, it's time to formally bring this forward. In this topic, I'll summarise the key points and link to further reading.

I suggest we have a brief chat about this tonight, but leave the main debate & vote until next week so that people have a chance to read the links below.

The proposal

• Matrix is accepted as equal to IRC for chat
• IRC remains a valid and supported option for those who wish to use it
• Matrix is promoted as the default option for new community members
• We hold regular introspection with the community to ensure we're still happy with the setup

Additional Information

Additional thoughts

• IRC is entirely acceptable but not friendly to new users
• Element (the glossy web-client from Element.io) provides a much more familiar environment for new users
• Matrix's structure allows us to stay connected with IRC (and potentially other networks)
• Further integration is possible, such as running our conferences on Matrix

More reading links:

• My long-form thoughts on the future path for chat
• Supporting data on network size and stability
• Blog posts from Thibault Martin of the GNOME Foundation (who use Matrix, Thib has written a lot on it)
• Blog posts from Mike Hoye of Mozilla on their successful transition last to Matrix last year

I have already spent some time collecting feedback from various community members. I plan to hold a video AMA next week (Tuesday, 3pm UK time when is this in local time?). I'll go through the way I see Matrix working for us, the feedback I've had so far, and take any more questions folks may have.

Summary

I raised this originally at ansible-collections/community.general#2501 (comment) but I will copy paste important bits here:

While trying to dump documentation (ansible-doc --json modulename) for all >5400 Ansible 3.4.0 modules, I discovered that 4 of them are missing documentation:

openstack.collect_logs.ara_influxdb.json
openstack.collect_logs.ara_graphite.json
fortinet.fortios.fortios_configuration_fact.json
cisco.intersight.intersight_local_user_policy.json

This should not have happened and is dangereus not to test exclisitely for this: that a clean ansible install does contain only modules with documentation, otherwise calling doc command on them will fail. That is easy to script as I already wrote some code that does that for the schemas project.

What we need to determine is which project is suppose to implement these safeguards, later we can even start to be more picky about how complete is the produced doc.

SUMMARY

Before Ansible 2.10, the project typically maintained N, N-1 for bug fixes and N-2 for security fixes. When Ansible 3.0.0 released, we suggested that we would no longer ship updated releases for 2.10.x unless someone needed it or showed up to do the work. Unless mistaken, we have not seen interest from the community so far in pursuing updates for 2.10.x.

The below HackMD link talks about the implications of maintaining updates for 3.x once 4.x releases and how we might support 4.x once 5.x releases and so on.

https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ

Summary

I'm not sure if there is already a policy for removing unresponsive maintainers of modules or not, but here is an example:
ansible-collections/community.general#1334 (comment)
which maintainers have not responded to mentioning them for almost 7 months.

Although I don't know if there is any value in removing maintainer's id from .github/BOTMETA.yml if they are not responsive and what would be appropriate response in this situation.

Summary

Issue:

Should we preemptively develop collection exclusion criteria and procedure?

This idea came to my mind when we discussed inclusion of equinix and inflobox collections.
This is still hypothetical but as we actively include collections, especially third-party ones, to the Ansible package, once it'll 99.9% happen that some of them will get unmaintained / broken / not complying to the requirements / unresponsive.

Moreover, if we can change things ourselves in repos under the ansible-collections GitHub organization, e.g. fix CI, review and merge PRs, release, find new maintainers and grant commit to them, maintain ourselves, etc., we can't do the same for third-party collection because, obviously, we don't have any permission there.

If we don't want Ansible ships a bunch of such stuff, we should develop the exclusion criteria and procedure.

Goals:

• Have them somewhere ready when needed.
• Motivate collection maintainers (especially third-party ones) to make their collections complying the collection requirements.

Solution:

• We could create a separate document under https://github.com/ansible-collections/overview
• Link to it from the collection requirements and ansible-inclusion README and from docs.ansible.com.

Initial view how it can basically look like:

1. Someone detects that the collection does not comply the collection requirements (we should go through third-party included collections from time to time to see how things are going there). If rough violations are found (I wouldn't define a precise list as it's hard to predict all possible cases and we should use our judgment and vote. If, say, a collection has a combination of a lot of issues with no response, broken CI, many not reviewed PRs OR, for example, locked issue tracker / its repo is archived, these are reasons to start the process).
2. An issue is raised in the collection repo pointing out the problem spots. If no response / no actions done, say, withing a month:
3. A dedicated issue is raised (say, in the ansible-inclusion repo) pointing out the problem spots and pinging people who submitted the collection and committers spotted in the collection repository.
4. Inform companies / individual maintainers by email if possible. If there's no reaction within a month since the dedicated issue is opened:
5. A related topic is raised in community-topics
6. Discussion, voting for / against exclusion of the collection in the next the Ansible package major release / the major release after the next one.
7. Announcement.
8. Exclusion.

Criteria (see step 1) will be abstract "Violations of the collection requirements". Each case should be considered individually.

The process can be suspended on any stage before exclusion if we see that the active work to make the collection complying is going.

Maybe it's too light:) Maybe if an exclusion decision is made, we shouldn't get back even if maintainers want to fix their collections. They can think "Ah, we have a lot of time and will fix our collection right before the exclusion and if the decision is finally made because the policy said that we can do it".
It takes a lot of time and effort for many contributors to review collection for inclusion, we will spend our meeting time to discuss and vote not discussing other important questions. Should it be easy for such collections to stay?

Summary

Right now, most 'old' community.collections (i.e. the ones which have been around since The Split and shortly after) support all Ansible/ansible-base/ansible-core versions since 2.9.10.

This is starting to put some strain on CI resources, since this means that tests need to run against stable-2.9, stable-2.10, stable-2.11, stable-2.12, and devel. In some collections like community.general, I've already started thinning out the test matrix for older Ansible versions, to avoid the CI matrix to grow too much. But growing the matrix gets harder for every stable-2.x branch that needs to be added.

Also, for community.general and community.network, we have a lot of symlinks to handle the flatmapping; for ansible-base 2.10 and newer we could use meta/runtime.yml instead, but Ansible 2.9 support requires symlinks. While symlinks aren't a problem in the collection artefact, they are a big problem in the Ansible tarball, since Python's setup.py de-duplicates symlinks. Therefore, all modules from these collections are contained twice in the Ansible tarball.

So for both these reasons, it would be nice to eventually get rid of Ansible 2.9 support, and also ansible-base 2.10 support. Unfortunately 2.9 is (inofficially?) a LTS version, so we have to be cautious when removing support for it.

(This is nothing we should and have to do now, i.e. for the new major releases targetted at Ansible 5, but rather for one of the next major releases, i.e. in 6-12 months.)

So, how long do you think we should still support Ansible 2.9 and ansible-base 2.10? And maybe we can come up with generic rules, like "only support the latest three stable-2.x branches + devel"? (Which would mean to drop support for stable-2.9 and stable-2.10 for community.general 5.0.0 and community.network 5.0.0 in Spring 2022.)

(Also individual collections can have different stable branch coverages; this would be more like a guideline for community collections which would mostly be followed by community.general and community.network.)

Summary

I've created several custom GitHub actions in the community.hashi_vault collection that could potentially be useful to others:
https://github.com/ansible-collections/community.hashi_vault/tree/main/.github/actions

I'm wondering if anyone else thinks so, and whether we should look to move some/all of these, and any new ones, to repositories hosted in the ansible-community namespace, both to centralize development of them and to make them available to anyone.

Summary of actions I have so far

• pull-ansible-test-images -- pulls the ansible test container images needed, separately from running the tests, to aid in separating the time taken (quay.io is slooooow) from the time taken to actually run the tests. Will probably eventually be supplanted by a dedicated ansible-test feature (but not in 2.9 probably): ansible/ansible#75320
• macos-docker -- installs docker on MacOS runners
• collection-via-git -- installs ansible collections directly from git repositories rather than galaxy, to avoid its downtime spurts interrupting CI
• ansible-codecov -- runs codecov in a way that can separate out the --group-by features of ansible-test into flags so you can see categorized coverage

Additional Information

No response

Summary

I'd like to change the settings on our rooms regarding chat history.

Previously we did not officially log the IRC channels, although many users keep their own log, and zodbot logs meetings. Right now, Matrix respects this - the rooms have Who can read history? set to Members only (since they joined) which also means if they leave and rejoin, they don't get the intervening messages.

This is not so bad for Matrix users because they are persistently connected to rooms anyway. However, there are several usecases for being able to read back up the history - it helps to understand if this is the right room for a question, to see the etiquette/norms of the room, and also to catch up on rooms you might only visit infrequently. It's also helpful because messages on Matrix have URLs, so you can direct people to previous answers, etc.

I'd like to change this setting to at least Members only (since the point in time of selecting this option) which essentially means a private log of the room - new people joining would get the history up until the time we set that option. However, we could opt to set it to Anyone which means a public log of the room - this means URLs work in an anonymous browser, and it also enables "peeking" where a new Matrix user can view the channel without joining - quite nice if you're not sure which room is the right one.

I don't think the former (Members only) is too controversial, as there already are many unofficial private logs of the channel happening. The latter (anyone) setting would be like having zodbot on all the time, you can view the history in your browser, and while I don't mind, I can see how it would not be to everyone's taste. In either case we'd need to put a logging notice in the room topics

So, to be discussed:

1. Are we ok with members only from now logging?
2. Do we go all the way to anyone logging?

Summary

Discuss community EE's:

1. prebuilt and published?
2. just sample manifest files?
3. discipline specific?

Additional thoughts:

This does not need to be a voting issue, probably best a conversation to surface thoughts and questions.

Some possible discussion topics:

What would the goal of embracing EEs be within the community:

• Encourage the use of EEs with navigator and AWX?
• Experience and familiarity?
• Alternate packaging format for community edition Ansible?

How far down the EE path?

• Full build and publish to quay? (plug and play)
• Reference definition files?
• Common repo for definitions? (EE def as code)
• A schema "describing" each EE
• Grouping and scope of EEs?
• Testing and validation?
• Frequency of build, if build?
• naming convention, labels (eg source URL to definition)
• What would the suggested base image be

From comments:

• doc implications/impact
• Encourage/suggest a requirements.txt per collection to aid in EE creation
• ansible-builder support for test removal during build to minimize size

Maybe related:

• Can/Should the community assist in the definition/default EE for ansible-navigator?

Should one or more steering committee members sponsor this effort and represent it moving forward?

Summary

Daylight savings will end in the places that observe it for only part of the year soon. Should we:

1. Keep the same time (18:00 UTC)
2. Move the meeting to 19:00 UTC (should make it the same time of day for people who do observe DST)
3. Something else?

If we change, what date should we change on?
2a) October 31 (most of the world)
2b) November 7 (US, Canada)

Any other proposals?

Summary

I have noticed that we currently carry servicenow.servicenow in the Ansible community package but it has been deprecated in favor of servicenow.itsm which is not in the package and has not yet filed for inclusion.

We should try to make sure this is addressed in time before the freeze for Ansible 5 with the appropriate redirects and deprecation messages as necessary.

Summary

ansible/ansible#75865

We generally try to do these at three week intervals. The date that's currently in the roadmap for 5.1 is five weeks from 5.0. This was because the release of 5.0 was originally planned for one week later so the date of the first maintenance release needed to be after the holidays. Now that we've moved the 5.0 release back by one week we have three weeks before the holidays to make the release.

Summary

The original planned schedule leading up to the release of Ansible 5 (as merged in this PR) needs to be revised since the release of ansible-core 2.12 has been delayed ~2 weeks: ansible/ansible#75350

Since the release of Ansible 5 is aligned shortly after the release of ansible-core 2.12, we need to update it to take into account the delay.

SUMMARY

Currently the newly submitted collection hpe.nimble for inclusion uses Apache-2.0 license which MUST be changed to GPL v3 as we only allow GPLv3+ (and optionally BSD-2-clause for module_utils).

Summary

I'd like to contribute https://github.com/mhansen/ansible-trace to ansible-collections.

Additional Information

Hi there, I've developed https://github.com/mhansen/ansible-trace, a tool for visualising where ansible execution time is spent.

I think this could have broad usefulness to the ansible community, and I wonder if the best way to increase it's reach is by contributing it to Ansible somehow.

I was chatting with @gundalow on https://www.reddit.com/r/ansible/comments/q49h2d/ansibletrace_visualise_execution_time_of_ansible/ and he suggested:

I'm wondering if this could be released as a standalone collection under https://github.com/ansible-collections/
u/markhnsn If you'd like to raise an issues here https://github.com/ansible-community/community-topics/issues we can use that to track the steps needed to move the repo over.

The repo now has a GPLv3 license. I imagine there might be some more steps to make this ready to land (just guesses):

• add tests
• maybe make sure it works on all versions of Python that Ansible supports

Summary

The work on Matrix is progressing well. We have had productive meetings with Element, and I have a long-form writeup of all my learnings so far in draft - I have been conversing with other FOSS communities that have either already moved to Matrix or are planning to, and discussing best practices. I will share that doc as soon as it's ready.

In preparation for that, I'd like to get our IRC channel modes set correctly. We have tested out the "+qe" strategy (see https://hackmd.io/k5xHgbpUTACRGPxNLru7ug for details) and that seems to be working well, we've had no further spam in that channel.

I'd like the community's blessing to go ahead and set those modes in all the channels listed under https://docs.ansible.com/ansible/devel/community/communication.html#working-groups (which I am replicating in a Matrix "space" at the moment) so that we are all set for proper interoperability / safety on both sides.

I may not be able to make the meeting in person to discuss further, but I hope this is not especially controversial as it is just a standardisation of our authentication and spam blocking policy across the Ansible IRC namespace.

Summary

Now that Ansible-4 has been released, it's time to nail down the Ansible-5 release schedule.

Here's a draft schedule for discussion:

https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw

Summary

There is a growing bit of Ansible related code inside ansiblelint.prerun which is shared with molecule and other projects.

While we considered moving this code to ansible-runner, @felixfontein and @tadeboro argued against such a move for a few reasons:

• not a community driven project, so making changes to it may be considerably harder
• it would bring some dependencies that we may no find any need for, at the moment. Examples pexpect and python-daemon.

This is why the current proposal is to create yet another small python library that would host the shared code, now hosted inside ansiblelint.

Once done we can also remove the dependency between molecule and ansible-lint.

At this moment the only thing preventing us from doing this change is agreeing on how to name that library. Please suggest only one name per comment and make use of thumbs up/down to vote on your preferred option. Lets see how easy we would address one of the most challenging activities in computer science.... naming.

Additional Information

No response

Summary

Starter ideas here: https://hackmd.io/lAJfWYrlT3Gg1VXYGBoZtA

CC @samccann

Summary

Ansible collection to scaffold a variety of plugin types based on user provided criteria.

This has already been committed to.

Decide on gh org and general conversation about community involvement.

What's the opportunity?

Provide tooling to scaffold out the basic python structure for all plugin types including:

• cache
• callback
• test
• filter
• inventory
• lookup
• connection
• action
• module
• vars

This would include the main plugin file for the specific plugin, as well as examples files in the respective utils directory

What's the approach?

• The use would populate a manifest file that would include things such as plugin name, plugin type, collection specifics, doc string, examples
• The playbook and corresponding collection would scaffold the python source files, with placeholders and/or examples code that the user would need to modify
• In the case of an action/module, additional information may be required such as: Can the plugin run on the control node? Will the plugin hit a REST API, Will the plugin use a 3rd party python package for logic and connection.
• The additional information can be used to steer the user toward the appropriate plugin type (action/module)

The intent is that ansible-plugin-builder be a living tools that improves over time based on a community and user feedback loop. Additionally, less well known approaches can be incorporated such as the use of the persistent connection framework, deriving the arspec from the doc string runtime, common code bases for filter and lookup, doc string for all plugin types, return value validation outbound

This should avoid the photocopy issue of plugins being built from other plugins, instead provide a starting point that incorporates good practices and techniques.

The work will start small, as a POC, and be iterated on over time.

Reference: Although this is very specific to network resource modules, the workflow and product may serve as a good example https://github.com/ansible-network/cli_rm_builder