開発環境構築の基礎からレゴ城造り、パートナー交渉術まで〜OpenStack Upstream Trainingの内容とは？（1/3 ページ）
OpenStack Summit Parisでは、数々の先進的な企業事例が登場した一方で、開発コミュニティ参加希望者に向けたオープンなトレーニングプログラムも企画されていた。OSSコミュニティのエコシステムの考え方まで考慮した2日間にわたるプログラムを、参加エンジニアがリポートします。
本稿では、2014年11月3〜7日にフランス・パリで開催されたOpenSack Summitに参加したユーザーらによるセッションレポートを紹介していきます。今回は、OpenStackコミュニティにおける開発のプロセスを学習するトレーニングプログラムの体験記です。誌上で追体験してみましょう。
なお、本稿で紹介する「OpenStack Upstream Training」は今回で3回目の開催である。第2回は日本で開催されており、その時の模様も紹介しています。第3回目の今回は、過去2回のフィードバックを盛り込んだ最新のプログラムになっています。
「OpenStack Upstream Training」とは？
筆者が参加した「OpenStack Upstream Training」は開発者を対象にしたトレーニングで、OpenStackのバグを修正するプロセスを実際に体験して、OpenStackへの貢献ワークフローを理解したり、OpenStackのリリースサイクルと企業の製品ロードマップへの統合に役立てるようなプログラムです。
トレーニングは3部屋に分かれて行われました。それぞれの部屋では、「公式トレーナー」3名が講師を務めています。今回は60名近くの参加者が集まりました。その他、APC（Active Program Contributors）やATC（Active Technical Contributor）もボランティアとして実習の手伝いに参加しています。APC、ATCなど、それぞれの役割については後述します。トレーニング全体の日程と講義内容はOpenStack Wikiのページで公開されています。
ここのところ注目を集めていることもあり、OpenStackの概要については、ここでは実際のトレーニングの内容に合わせて、基本的な情報から紹介していきましょう。
開発者はコードネームが基本
まず、OpenStackは6カ月ごとにリリースされます。コミュニティの方々は普段は正式バージョン名を使わず、「Juno」などのコードネームで呼びます。直近のバージョンで言うと次のような表記です。
- Havana → 2013.2
- Icehouse → 2014.1
- Juno → 2014.2
- Kilo → 2015.1
バージョン表記は＜リリースした年＞.＜x番目のリリース＞で表記されます。つまり最新版であるJunoは2014年に2番目にリリースされたバージョンであることが分かります。
OpenStackリリースまでのプロセス
当日のプログラムでは、次にリリースまでの流れが解説されました。開発方針決定からリリースまでの流れを時系列に示すと右図のようになります。
ぞれぞれのプロセスと目的を確認していきます。
1.「Design Summit」
新しい開発を行うとき、必ずDesign Summitを開いて関係者が直接フェーストゥフェースで協議をします。
Design Summitは通常、OpenStack Summitと同時期に行われます。今回の「Kilo Design Summit」は、OpenStack Summitの2日目、11月4日からスタートしました。
2.「Planning: Discuss」
Design Summitを行う前に、候補となる新機能などをBlueprints（設計書）に記述していきます。設計書は以下のページに作成されていきます。
議論や新機能の追加候補であるパッチのリンクがまとめられていきます。Blueprintsにおける議論の期間は4週間ですが、Design Summitそのものは、前述のようにOpenStack Summitの会期と合わせつつ、この期間中の第3週目に設定されます。
3.「Planning: Target」
機能ごとのマイルストーンを設定します。Program Technical Leads（PTL）が優先度を決めます。
4.「Implementation」
以前から新機能のパッチがある場合を除いて、議論の末に、新しく決められた機能はこの期間で実装していきます。この期間にいくつかのデッドラインが設定されます。
以下に主なデッドラインの設定を挙げておきましょう。なお、かっこ内は、それぞれのデッドラインが誰のために設定されているものかを示しています。
- Feature proposal freeze（For Coder＝実装する人たちのため）
このタイミングで機能が決定されます。これ以降の新機能追加は行われません - Feature freeze 実装作業が終了します
- String freeze（For translator＝文字列の翻訳を行う人たちのため）
Feature freezeとほぼ同じ日程で終了となり、出力される文字列が確定します - Dep Freeze（For packager＝Linuxディストリビュータなどパッケージを行う人たちのため）
OpenStackのコンポーネントごとに関連するライブラリ、バージョンが決定します。言い換えると、インストールする際の依存関係が確定することになります
プロジェクトではそれぞれのデッドラインを守りながら、実装が進められます。
5.「Release Candidates（リリース候補）」
次に、リリース候補がビルドされます。ここからバグ投稿、修正、ドキュメント作成が始まります。さらに、OpenStackの全コンポーネントがそれぞれ持っているバージョン名も同期していきます。残作業に応じて「RC（Release Candidate）1」「RC2」など数回公開されていきます。最後のRCが最終リリースコンポーネントとなり、アナウンスされます。
リリース後、約1カ月の休暇（推奨）期間の後、次のDesign Summitが始まります。OpenStackの開発コミュニティでは、このサイクルに従って開発が続けられています。
開発に関わるステークホルダーの種類と権限
続いてコミュニティの関係者を見ていきましょう。開発コミュニティは以下のようなステークホルダーで構成されています。それぞれの役割と共に紹介しておきます。
1.「Technical Committee」（TC、技術委員会）
OpenStackの今後の方針を決め、コミュニティ全体をリードしていく人たちです。OSSコミュニティに慣れ親しんでいる読者ならば、その他のOSSの大きな団体でもこのような権限を持つ人たちが存在していることをご存じかと思います。彼らは毎週IRC（irc.freenode.netの#openstack-meetingチャネル）上で会議をしています。
2. 「Program Technical Leads」（PTL）
TCの下に付いている方々で、日々の問題解決や議論の取りまとめを行っています。
3.「Active Program Contributor」（APC）
OpenStack Foundationの個人会員から推薦などで選定され、企業に依存しない独自の判断が求められます。
PTLの有権者です。任期は就任から1年間と決められています。
4.「Active Technical Contributor」（ATC）
APCと基本的に同じですが、PTLではなくTCの有権者であり、候補者は推薦することができます。任期は2回のリリースサイクル分（約1年間）と決められています。彼らは無償でOpenStack Summitに参加することができ、バグのステータス管理やドキュメント作成を行います。
Copyright © ITmedia, Inc. All Rights Reserved.