Red Hatのさいとうです。この記事はAnsible Advent Calendarの12月9日の記事です。今回は、地味であまり知られていないAnsible Collectionsのメンテナの仕事についてご紹介しようと思います。
Ansible Collectionsとは
Ansible2.9までは、Playbookを処理するエンジン部分と、モジュールやプラグインなどコンポーネントをあわせて、AnsibleというOSSプロダクトとして提供していました。
この提供形態が、2.10で大きく変更されて、現在のAnsibleでは以下の2つのサブコンポーネントに分離され、この2つをあわせたものをAnsibleとしてバージョニングして提供しています。
2.9以前からAnsibleを利用している方に馴染深い2.x.zというバージョニングは、現在では1.のAnsible Coreのバージョンとして採用されています。
- Ansible Core: ansible-playbookコマンドなどのPlaybookを実行するためのエンジン部分と、核となる少数のモジュール、プラグイン群
- Ansible Collections: Ansible Coreに含まれないモジュール、プラグイン、ロールをまとめてジャンル毎にまとめてたもの
Collectionsごとに専用のリポジトリが存在していて、Ansible Coreとは独立したリリースサイクルをもっています。そして、他のOSSと同様に、それぞれのCollectionsには、リポジトリを管理するメンテナが任命されています。
Ansible Collectionsの場合の任命プロセスは、特に決まっておらず、なんとなく大量にPullRequestなげていると、現行メンテナから他のPullRequestのレビュー依頼がくるようになって、レビューを続けていると、「ちょっとメンテナやってみない?」といった感じで誘われることが多いようです。また、それぞれのCollectionsのリポジトリに、Issueとして「メンテナ募集!」といったタイトルでIssueがオープンされて、メンテナを公募することもあるようです。この場合も、「過去にどれくらい積極的に係わってくれているのか」という点が問われます。
Ansible Collectionsへの係わり方
CollectionsもOSSですので、皆さんさまざまな係わり方をしているのではないでしょうか?
- Collectionsを利用する
- バグや機能追加などのフィードバックをする
- 修正や機能追加などをコード実装する
- 報告されたバグや、投稿された修正・機能追加コードをレビューする
- Collectionsのリポジトリを管理する
Ansible Collectionsのメンテナのお仕事は、5.にあたります。厳密には報告されたバグや機能追加リクエストにしたがって、コードを書いたり修正したりするといった役割は、実はメンテナの仕事ではありません(実際にはしてるけど)。
Ansible Collectionsメンテナのお仕事
メンテナのお仕事ガイドラインは、Ansibleのコミュニティーチームからのガイダンスにまとめられていますが、ほとんどは口伝です。 [ansible.posix]コレクションを例にして、ひっそりと行っているメンテナのお仕事をご紹介します。
利用者から寄せられるバグや機能追加などのフィードバックのトリアージとクローズ
利用者が報告してくれた(してくれた <- 感謝のお気持ち。ここ大事)バグレポートや機能追加リクエストを確認して、適切にラベリングします。ansible.posixでトリアージに利用している主なラベルは以下の通りです。
- needs_triage: モジュールの作成者やメンテナが報告された情報を精査している(してないかもしれないけど、とりあえず付与)
- needs_verified: バグの再現やワークアラウンドの検証、機能追加リクエストであれば既存の機能などかないかどうかを確認中
- needs_info: 報告者からの情報が足りない。通常はIssueのコメントで追加情報を求めている
- verified: 確認完了
- bug: はい、それバグです
- feature: お、その機能あるといいね
- waiting_on_contributor: 再現してくれるひとやコードを書いてくれるひと求む
- has_pr: IssueとセットになったPullRequestが存在していからリンクしておいたよ
Collectionsによっては、moduleやpluginといった、レポートされた対象のコンポーネントにしたがってラベルを付与している場合もあるようですが、僕は基本的に上記のラベルだけでやりくりしています。細い管理が苦手なタイプなので。
オープンされたものは、いつかクローズする時がくるものです。PullRequestによって不具合が解消されたり機能が追加された場合や、報告者の環境に依存した問題が原因で不具合が発生していたといった場合は、コメントしたうえでIssueをクローズしています。
IssueやPullRequestのトラッキング
PullRequestのレビューをレビュアにお願いしたり、Issueの調査が難航しそうであれば、モジュールのAuthor(だいたい見てない)に連絡して調査の進展をうながすといった交通整理を行います。
また、PullRequestのCIテストが失敗しているような場合は、テストログをチェックしてPullRequestのオーナーに変更依頼を出すといったことも行います。
Ansible Coreの変更に対する対応
Ansible Collectionsは、CIテストにAnsible Coreのansible-testコマンドを利用しています。そのため、Ansible Core側でansible-testの仕様が変更されると、その影響の直撃を受けます。Ansibleが1つのプロダクトだった時代は、特にこの影響はありませんでしたが、Ansible CoreとCollectionsに分離されたタイミングから、Ansible Coreの仕様変更を常にトラッキングして、その変更に追随する必要がでてきました。
このように、Ansible Coreの変更によってCollectionsが何らかの影響を受ける場合、Ansibleのコミュニティーチームが、以下のサイトにIssueとして報告をあげてきます。これを常時チェックして、その変更の影響を吸収する措置を考えて、CI環境のパラメータを調整するといった作業がこれにあたります。
- https://github.com/ansible-collections/overview/
- 例: Changes impacting Collection Contributors and maintainers #45
PullRequestのマージ
レビューが完了したPullRequestにgateラベルを付与します。メンテナによってgateラベルが付与されると、そのPullRequestは再度CIテストが実施されて、これにパスすると自動でマージされる仕組みです。
Collectionsでは、コードのマージプロセスに、プロジェクトゲートシステムのZuulを利用してるため、メンテナが直接PullRequestをマージすることはありません。
リリース計画の策定と実行
メンテナの間で、「そろそろやろうか?」とリリース計画を策定します。通常は、これもオープンにIssueで議論されます。以下は、community.generalコレクションの例です。
Collectionsでは、良きタイミングでリリースタグを打ってアーカイブを作成します。Ansible Coreと分離されたおかげで、各Collectionsのメンテナが独自のリリースサイクルで新バージョンをリリースできるようになっています。ありがたい。
新バージョンのアーカイブは、自動でGalaxyにアップロードされるので手間いらず。
最後に、IRCとコミュニティニュースレター用のIssueを更新してリリース完了です。
まとめ
メンテナとしての仕事も、整理してみると意外にやることが多く、自分でも少し驚いています。
僕の場合は、幸いなことにAnsibleチームに在籍しているということもあって、Red Hatでは、このようなOSSのAnsibleに貢献する活動が公認されています。超絶優秀な同僚にサポート業務を丸投げしてリリース対応といったこともできる環境です。こういう会社のカルチャー本当に大事。
いつもカバーしてくれている同僚と、それを認めてくれている会社に感謝しつつ、今回の記事を締めたいと思います。みんなありがとうね!
