OpenStack は非常に活発なコミュニティに支えられており、あなたの参加をいつでも待っています。この章では、コミュニティーの他の人と交流する方法について詳しく説明します。
助けを探すために利用できる方法がいくつかあります。最も早い方法は、あなたを手伝ってくれるコミュニティーを支援することです。あなたの問題に近いものについて、Q&A サイト、メーリングリストの過去ログ、バグ一覧を検索します。何も見つけられなければ、バグを報告して指示に従うか、以下のリストにまとまっているサポートチャンネルのどれかを使用します。
最初に確認すべき場所は OpenStack の公式ドキュメントです。 http://docs.openstack.org にあります。また、http://ask.openstack.org で質問と回答を参照することができます。
メーリングリスト もアドバイスをもらうのに素晴らしい場所です。 Wiki ページにメーリングリストの詳しい情報が載っています。運用者として確認しておくべき主要なメーリングリストは以下です。
- 一般向けメーリングリスト
openstack@lists.openstack.org。このリストは、OpenStack の現行リリースに関する話題を取り扱います。流量が非常に多く、1 日にとてもたくさんのメールが流れます。
- 運用者向けメーリングリスト
openstack-operators@lists.openstack.org.。このメーリングリストは、あなたのように、実際に OpenStack クラウドを運用している人々での議論を目的としています。現在のところ、メールの流量は比較的少なく、1 日に 1 通くらいです。
- 開発者向けメーリングリスト
openstack-dev@lists.openstack.org。このリストは、OpenStack の今後についての話題を扱います。流量が多く、1 日に複数のメールが流れます。
一般向けリストと運用者向けリストを購読するのがお薦めです。一般向けリストの流量に対応するにはフィルタを設定する必要があるとは思いますが。 Wiki のメーリングリストのページにはメーリングリストのアーカイブへのリンクがあり、そこで議論の過程を検索することができます。
一般的な質問用や開発者の議論用など、 複数の IRC チャネルがあります。一般の議論用のチャネルは irc.freenode.net の #openstackです。
運用者として、あなたは、あなたのクラウドでの予期しない動作を報告できる非常によい立場にいます。 OpenStack は柔軟性が高いので、ある特定の問題を報告するのはあなた一人かもしれません。すべての問題は重要で修正すべきものです。そのためには、簡単にバグ報告を登録する方法を知っておくことは欠かせません。
全ての OpenStack プロジェクトでは、バグ管理に Launchpad を使っています。バグ報告を行う前に、Launchpad のアカウントを作る必要があります。
Launchpad のアカウントを作った後は、バグを報告するのは、問題の原因となったプロジェクトを特定するのと同じくらい簡単です。場合によっては、思っていたよりも難しいこともありますが、最初のバグ報告が適切な場所でなかったとしても、バグの分類を行う人がバグ報告を適切なプロジェクトに割り当て直してくれます。
nova のバグ報告。
python-novaclient のバグ報告。
swift のバグ報告。
python-swiftclient のバグ報告。
glance のバグ報告。
python-glanceclient のバグ報告。
keystone のバグ報告。
python-keystoneclient のバグ報告。
neutron のバグ報告。
python-neutronclient のバグ報告。
cinder のバグ報告。
python-cinderclient のバグ報告。
manila のバグ報告。
python-manilaclient のバグ報告。
python-openstackclient のバグ報告。
horizon のバグ報告。
ドキュメント のバグ報告。
API ドキュメント のバグ報告。
よいバグ報告を書くには、次に述べる手順を踏むことが不可欠です。まず、バグを検索し、同じ問題に関してすでに登録されているバグがないことを確認します。見つかった場合は、"This bug affects X people. Does this bug affect you?" (このバグは X 人に影響があります。あなたもこのバグの影響を受けますか?) をクリックするようにして下さい。同じ問題が見つからなかった場合は、バグ報告で詳細を入力して下さい。少なくとも以下の情報を含めるべきです。
実行しているソフトウェアのリリースやマイルストーン、コミット ID
あなたがバグを確認したオペレーティングシステムとそのバージョン
バグの再現手順。何がおかしいかも含めてください
期待される結果の説明 (出くわした現象ではなく)
関連部分のみを抜粋したログファイル
バグ報告をすると、バグは次のステータスで作成されます。
Status: New
バグのコメントでは、既知のバグの修正方法に関して案を出したり、バグの状態を Triaged (有効な報告か、対応が必要かなどを分類した状態) にセットすることができます。バグを直接修正することもできます。その場合は、バグを自分に割り当てて、状態を In progress (進行中) にセットし、コードのブランチを作り、マージしてもらうように変更を提案するという流れになります。でも、先走りし過ぎないようにしましょう。バグを分類するという仕事もありますから。
このステップでは、バグが実際に起こるかのチェックやその重要度の判定が行われます。これらのステップを行うには、バグ管理者権限が必要なものがあります (通常、バグ管理権限はコア開発者チームだけが持っています)。バグ報告に、バグを再現したりバグの重要度を判定したりするのに必要な情報が不足している場合、バグは
Status: Incomplete
にセットされます。問題を再現できた場合 (もしくはこの報告がバグであると 100％ 確信を持てる場合) で、セットする権限を持っている場合には、
Status: Confirmed
にセットして下さい。
Importance: <バグ影響度>
バグ影響度は以下のカテゴリに分かれています。
Critical このバグにより、目玉となる機能が全てのユーザで正常に動作しない場合 (または簡単なワークアラウンドでは動作しない場合)、データロスにつながるような場合
High このバグにより、目玉となる機能が一部のユーザで正常に動作しない場合 (または簡単なワークアラウンドで動作する場合)
Medium このバグにより、ある程度重要な機能が正常に動作しない場合
Low このバグが多くの場合で軽微な場合
Wishlist 実際にはバグではないが、そのように動作を変更した方よいものの場合
バグ報告に解決方法やパッチが書かれている場合、そのバグの状態は Triaged にセットされます。
この段階では、開発者が修正を行います。修正を行っている間、作業の重複を避けるため、バグの状態を以下のようにセットすべきです。
Status: In Progress
Assignee: <あなた自身>
修正が用意できたら、開発者は変更を提案し、レビューを受けます。
この本をここまで読んで来たので、あなたはコミュニティーの正式な個人メンバーになって、OpenStack Foundation に加入する (https://www.openstack.org/join/) ことを考えていることでしょう。 OpenStack Foundation は、共有リソースを提供し OpenStack の目的の達成を支援する独立組織で、OpenStack ソフトウェア、およびユーザ、開発者、エコシステム全体といった OpenStack を取り巻くコニュニティーを守り、活力を与え、普及の促進を行います。我々全員がこのコミュニティーをできる限りよいものにしていく責任を共有します。メンバーになることはコミュニティーに参加する最初のステップです。ソフトウェア同様、 OpenStack Foundation の個人会員は無料で誰でもなることができます。
OpenStack のドキュメント作成活動は、運用管理ドキュメント、API ドキュメント、ユーザドキュメントなどに渡ります。
この本の元は人が集まったイベントで作成されましたが、今やこの本はみなさんも貢献できる状態になっています。 OpenStack のドキュメント作成は、バグ報告、調査、修正を繰り返し行うというコーディングの基本原則に基いて行われています。
Just like the code, http://docs.openstack.org is updated constantly using the Gerrit review system, with source stored in git.openstack.org in the openstack-manuals repository and the api-site repository.
公開される前にドキュメントのレビューを行うには、OpenStack Gerrit サーバー http://review.openstack.org に行って、project:openstack/openstack-manuals や project:openstack/api-site を検索して下さい。
ドキュメントのレビューや変更を最初に行うのに必要な手続きについての詳しい情報は、Wiki の How To Contribute ページを参照して下さい。
我々は、コミュニティーとして、セキュリティーを非常に重要だと考えており、潜在的な問題の報告は決められたプロセスに基いて処理されます。修正を用心深く追跡し、定期的にセキュリティー上の問題点を取り除きます。あなたは発見したセキュリティー上の問題をこの決められたプロセスを通して報告できます。OpenStack 脆弱性管理チームは、OpenStackコミュニティーから選ばれた脆弱性管理の専門家で構成されるごく少人数のグループです。このチームの仕事は、脆弱性の報告を手助けし、セキュリティー上の修正の調整を行い、脆弱性情報の公開を続けていくことです。特に、このチームは以下の役割を担っています。
- 脆弱性管理
コミュニティメンバー (やユーザー) が発見した全ての脆弱性はこのチームに報告されます。
- 脆弱性追跡
このチームはバグ追跡システムに登録された脆弱性に関連する問題の管理を行います。問題の中にはこのチームおよび影響を受けるプロジェクトの責任者のみが参照できるものありますが、問題の修正が用意されると、全ての脆弱性は公開されます。
- Responsible Disclosure（責任ある情報公開）
セキュリティーコミュニティーと仕事をする責務の一つとして、セキュリティー情報の公開が、確実に、そしてOpenStack のセキュリティー問題を責任をもって扱うセキュリティ研究者の適切なお墨付きを得て行われるようにします。
OpenStack 脆弱性管理チームに問題を報告する方法は 2 種類用意されており、問題の重要度に応じて使い分けて下さい。
Launchpad でバグ報告を行い、「security bug」のマークを付ける。マークを付けると、そのバグは一般には公開されなくなり、脆弱性管理チームだけが参照できるようになります。
問題が極めて慎重に扱うべき情報の場合は、脆弱性管理チームのメンバーの誰かに暗号化したメールを送って下さい。メンバーの GPG 鍵は OpenStack Security で入手できます。
あなたが参加できるセキュリティー関連のチームのリストは セキュリティーチーム にあります。脆弱性管理プロセスはすべてドキュメントにまとめられており、脆弱性管理 で参照できます。
この本以外にも、OpenStack に関する情報源はたくさんあります。 OpenStack ウェブサイト は最初に見るといいでしょう。ここには、OpenStack ドキュメント と OpenStack API ドキュメント があり、OpenStack に関する技術情報が提供されています。OpenStack wiki には、OpenStack の各プロジェクトの範囲にとどらまらない汎用的な情報が多数あり、例えば 推奨ツール といった情報も載っています。最後に、Planet OpenStack には多くのブログが集められています。