OpenStack Ansible モジュール

これらは、管理者またはエンドユーザーとして、 OpenStack と対話するためのモジュールセットです。モジュールの名前が os_ で始まらない場合は、非推奨になっているか、 まもなく非推奨になります。本ガイドは、 ここにあるモジュールの開発者向けコーディングガイドラインとなるように作成されています。

命名規則

• すべてのモジュール名は os_ で始めることができます。
• クラウドコンシューマーが管理する論理リソースの後に使用する予定のモジュールに、os_nova ではなく os_server という名前を付けます。この命名規則は、エンドユーザーがどのサービスがリソースを管理するか (つまり、デプロイメントの詳細) を気にしないことを理解しています。たとえば、クラウドコンシューマーが、フローティング IP が Nova と Neutron のどちらによって管理されているかを知らない場合があります。
• クラウド管理者がサービスおよびリソースで使用する予定のモジュールに名前を付けます (os_keystone_domain)。
• モジュールがクラウド管理とクラウドコンシューマーの両方で使用できる場合は、 クラウドのコンシューマールールが適用されます。

インターフェース

• 管理されているリソースに ID がある場合は、その ID が返されます。
• 管理されているリソースに、 ID よりも複雑なオブジェクトが関連付けられている場合は、それも返す必要があります。

相互運用性

• クラウドコンシューマーは、 クラウドプロバイダーが行ったデプロイメントの選択に関する膨大な詳細を顧客が知らないと想定して、 デプロイ担当者がむちゃくちゃなことをしても、 1 つの適切なインターフェースを Ansible ユーザーに提示するように最善の努力をする必要があります。
• すべてのモジュールは、 既存で、既知の全パブリック OpenStack クラウドに対して適切に機能するはずです。
• 複数のクラウドアカウントがあり、 1 つの Ansible 管理インフラストラクチャーとしてまとめたい可能性があると想定する必要があります。

ライブラリー

• すべてのモジュールは、openstack_full_argument_spec を使用して、 auth や ssl サポートなどの標準入力を取得する必要があります。
• すべてのモジュールには extends_documentation_fragment: openstack が含まれている必要があります。
• すべての複雑なクラウドインタラクションまたは相互運用性コードはすべて、 openstacksdk ライブラリーに保存する必要があります。
• すべての OpenStack API 対話は、 OpenStack クライアントライブラリーではなく、openstacksdk を介して行われる必要があります。OpenStack Client ライブラリーには、 主要な対象ユーザーとしてのエンドユーザーはなく、サーバー内通信用です。

テスト

• 統合テストは現在 OpenStack の CI システム で行われています。
• openstacksdk でテストすると、鶏と卵のシナリオが理解できます。PRを発生させて、 直接報告するための作業が進行中です。