Crypto Pinboard

[felixfontein]

Welcome to the community.crypto pinboard! Please subscribe if you are interested in general topics on community.crypto!

Continues ansible/community#444

[felixfontein]

FYI: I'm currently working on generalizing Ansible's internal changelog generator to collections (https://github.com/felixfontein/ansible-changelog/) and ACD, and here's the current changelog for 1.0.0 (as "the next release after Ansible 2.9"): https://github.com/felixfontein/community.crypto/tree/changelog-1.0/changelogs

In particular, here's the generated ReST file: https://github.com/felixfontein/community.crypto/blob/changelog-1.0/changelogs/CHANGELOG-v1.rst

And here's the generated YAML file (ansible-collections/overview#18 (comment)) which is the changelog in machine-readable format (will be used for creating ACD changelog): https://github.com/felixfontein/community.crypto/blob/changelog-1.0/changelogs/changelog.yaml

[felixfontein]

I never followed up to the last comment: the combined changelog for Ansible 2.10 is here: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst

Anyway, if you haven't done so, check out #74 (release plan) and subscribe to it to get updated on discussions/information about new releases. Finally, there are two bugfix PRs which could use a review: #108 and #109. With these included, I propose a 1.1.1 release soon which would get included in Ansible 2.10.0.

[felixfontein]

Please note that we now have an issue for release planning (and release) announcements: #127

We also have issues for planning the next release (1.3.0): #126, and for planning the 2.0.0 release: #128

[felixfontein]

Beginning of December, Ansible and all collections using Shippable (i.e. also us) are migrating from Shippable to Azure Pipelines (ansible-collections/overview#124). community.crypto will be one of the first collections to migrate. This mainly means that CI might not be perfectly working during that time; since Shippable will only be removed after AZP works, it shouldn't be too bad.

[felixfontein]

@Spredzy @Xyon @Shaps @MarkusTeufelberger @puiterwijk @resmo if anyone of you has a bit of time, I would be glad if you could take a look at some of my open PRs: #150, #163, #166, #167

[felixfontein]

The last Ansible 2.10.x release will probably happen next Tuesday (January 26th), so it would be great if we could make a release before that. Would be nice if at least some of the PRs could make it in!

[felixfontein]

I started writing some guides for creating certificates (for the moment, using the selfsigned and ownca providers) at #237. Any feedback/reviews/... welcome!

[felixfontein]

We're happy to announce that the registration (free) for the Ansible Contributor Summit is open.

Which day should you attend?

• If you are wondering what it means to "contribute" to Ansible, or if you have been using Ansible for a while and are thinking of ways to get more involved with the project and community, then Day 1 (September 28, Tuesday) is for you!
• If you have already been contributing or participating in our previous Contributor Summits, you are still welcome to attend Day 1, however we think that Day 2 (October 1, Friday) will be more interesting for you.

Refer to the registration page for details.

See you at the summit!

[dericcrago]

Reminder - AnsibleFest and Ansible Contributor Summit are 1 week away!

In case you missed it, we will also be having a Hackathon throughout the entire Ansible Contributor Summit and AnsibleFest. This is a great opportunity to collaborate in real time with other members of the Ansible Community!

For more info and the latest updates, please see the Ansible Contributor Summit 2021.09 HackMD.

[felixfontein]

The discussion on whether to add a replacement for the assertonly provider is still not concluded. I've added my (current) opinion to it in #76, and I would be really glad if more people could pitch in, whether we still need a verification module like the assertonly provider or whether other mechanics (using the _info module, idempotency of other modules, ...) are enough.

[felixfontein]

I suggest we drop support for Ansible 2.9 and ansible-base 2.10 in the next major release. Both will be EOL in May 2022 anyway, and some versions of both cause problems (see #371). I think we should also have some policy when we drop support for ansible-core versions, and/or stop testing against them. I would suggest to strip EOL'ed ansible-core versions to minimal testing in CI (also so our CI matrix does not grow unbounded) and drop support for all EOL'ed ansible-core versions (and the ones which will EOL in the next 1-2 months) on every major release.

Does that sound reasonable? Any feedback, other ideas, ...?

(See also ansible-community/community-topics#50 for a similar discussion for community.general and community.network.)

[felixfontein]

Right now we're using issues to track minor releases. @briantist suggested to use milestones here. I think that definitely makes sense for minor releases; for major ones I'd still have an issue (next to a milestone). What do you think?

[felixfontein]

If anyone is interested in Execution Environments, please take a look here: #440 (comment)