OpenStack開発者メーリングリストの要約 1月14日～20日

OpenStack開発者メーリングリストの要約 1月14日～20日第03回　17年02月 / 最終更新：2017.02.09

こんにちはー。野田貴子です。今回は開発者メーリングリストの要約版を送付します。昨今、OpenStackの注目度が高まっており、OpenStack開発者メーリングリストやコラムをチェックしている人も多いと思います。英語が苦手な方にとっては、日本語で要約版があると助かるのではないかと考え、月間のダイジェストとして日本語訳したものをお伝えすることにしました。

以下の意訳文をお読みいただき、興味があるもののみ英文の原文を読まれるとよいと思います。
興味がある方はご参考ください。海外動向を理解する上での参考になれば幸いです。

###

SuccessBot より

●stevemar（1）：対応中のKeynoteのバグ数が100以下になりました！
●morgan（2）：よいポリシーミーティングでした。多くの混乱を解消した歴史や背景が述べられました。
●OpenStack IRC チャンネルから「#success <message>」という書式でみなさんの状況を教えてください。
●すべて

FIPS準拠

●以前のスレッド（3）では、FIPS（Federal Information Processing Standards）の有効化について議論が行われました。
●さまざまなOpenStackプロジェクトがmd5呼び出しを行います。セキュリティ目的ではなく、
　ハッシュ生成だけでなく、FIPSの有効化をブロックしています。
●Pythonの最新バージョンでは、ユーザーがセキュリティのために使用するかどうかを設定するためのパッチが提案されています（4）。
　　　○Pythonの次のバージョンまでは提供されませんが、現在のRHELおよびCentOSバージョン用には提供されます。
　　　○useforsecurity = Falseパラメータでmd5のラッパーを作成し、hashlib.md5の署名をチェックする予定です。
●今後のステップ：
　　　○ラッパーの作成
　　　○OpenStackプロジェクトのすべてのmd5呼び出しをラッパーに置き換えます。
●残念ながら、このパッチ（4）は2013年以降進歩を止めています。まずはこれをマージしなければなりません。
　　　○これが着地したとしても、Python 3.7に移植されるので、採用されるまでにはしばらく時間がかかるでしょう。
●全スレッド

API互換性ガイドラインの更新と再検証

●最後のTCミーティング（5）では、APIの互換性をサポートするためのタグが検討されました（6）。
●タグは、旧式のAPIガイドラインを使用してプロジェクトを評価しています（7）。
　　　○これらのガイドラインを更新するためのレビューが掲載されました（8）。
　　　○超過時間のAPI互換性は、OpenStackの相互運用性の基本的な側面です。
　　　　これを正しいものにする必要があるだけでなく、みんなが理解していることを確認する必要があります。
●全スレッド

基本サービス

●OpenStackでは、すべてのコンポーネントで多数の外部サービスが存在せず、利用可能ではないと仮定することができます
　（例えば、メッセージキューやデータベースなど）。
●Architectureワーキンググループはこの取り組みを開始しました（9）。
●この提案（10）は、私たちが基本サービスの追加についてより戦略的な議論をするための前提条件です。
●提案をレビューしたり、Architectureワーキンググループのミーティングに参加したりしましょう（11）。
方針が固まれば、テクニカルコミッティーが最終的な議論と承認を行うでしょう。
●全スレッド

ベンダーの見つけやすさの改善

●これまでのテクニカルコミッティーの会議で、ベンダーの見つけやすさを改善する必要があることが合意されました。
●これは、OpenStack Foundationマーケットプレイスですでに行われています（12）。
　　　○これはコミュニティ主導のプロジェクト呼出しドライバーログ（大きなJSONファイル）によって実行されます（13）。
●コミュニティの多様な人々はこのマーケットプレイスがどのように働いているのかを知らず、
　プロジェクト自体がこのファイルを所有していなかったことに不満を抱いていました。
●この議論の目的は、このプロセスを今よりもコミュニティ主導的にすることです。
●提案：ドライバーログをより小さなJSONファイルに分割し、それらを各プロジェクトの中に置いて管理しましょう。
　　　○プロジェクトは、このリストのベンダーをどのように検証するかを設定します。
　　　○今日、サードパーティ製のCIが検証の選択肢となっている傾向があります（14）。
●全スレッド

OpenStack PTLのノミネートがオープンしました！

●2017年1月29日23:45 UTCまでオープンしています。
●候補者はテキストファイルをopenstack/electionレポジトリに提出してください（15）。
　　　○ファイル名の規則は$サイクル名/$プロジェクト名/$IRC名.txtです。
　　　○資格を得るためには、NeutronからOcataの間（2016年4月11日00:00 UTCから2017年1月23日23:59 UTCまで）に、
　　　　対応するプログラムのプロジェクト（16）の1つに承認済みのパッチを提供してください。
●推薦プロセスに関する追加情報はこちらです（17）。
●承認された候補者はリスト化されます（18）。
●有権者は2017年1月25日23:59 UTCより前に、設定→連絡先→優先メールのGerrit（19）でメールアドレスを確認する必要があります。
●全スレッド

stable/ocataブランチの作成プロセス

●前述（20）のように、準備ができたチームはstableブランチをセットアップすることができます。
●リリースチームはこのサイクルでブランチを自動的に設定することはありません。
　　　○準備ができたらチーム内でリリースの通知を行う必要があります。
　　　○PTLまたはリリース通知は、ブランチのベースとして使用されるタグ付きバージョンを指定して、
　　　　パッチをopenstack/releasesリポジトリに送信することによって、新しいブランチを要求することができます。
●プロジェクトのブランチ時期に関するガイドライン：
　　　○マイルストーン・サイクルのリリースモデルを使用するプロジェクトでは、stableブランチのリクエストとRC1タグのリクエストを
　　　　含めてください（ターゲットはR-3週なので、2月2日を期限とします）。
　　　○ライブラリのプロジェクトは、今週の最終リリース（1月19日を締め切りとします）と同時に、または直後にブランチしてください。
　　　○私はマイルストーン・サイクルのすべてのプロジェクトがブランチされた直後に要件リポジトリをブランチします。
　　　　要件リポジトリがブランチされmaster要件リストがオープンされた後、ブランチされていないプロジェクトは、
　　　　masterブランチの要件が進歩し、stable/ocataが安定したままであることをPikeの要件でテストされます。
　　　　stable/ocataブランチを作成するのに時間がかかりすぎると、stable/ocataまたはmasterのCIジョブが壊れる可能性があります。
　　　　必要以上に遅らせないようにしてください。
　　　○追跡サイクルのリリースモデルを使用するプロジェクトは、R-0（2月23日）までにブランチしてください。
追跡締め切り前の2週間は、最終的なリリースを作成するためにブランチにバックポートする必要がある直前の修正に使います。
　　　○仲介サイクルのプロジェクトやブランチを作成する独立プロジェクトなどのその他のプロジェクトは、
　　　　最終バージョンを宣言しPike関連の変更作業を開始する準備が整ったら、stableブランチを要求してください。
　　　　これは最終リリース週の前に完了しなければならず、2月16日を期限とします。
●ブランチの書式を設定する方法の詳細については、openstack/releasesのREADME.rstファイルを参照してください。
●全スレッド

未だにプロジェクトでBarbicanを避けようとしている理由

●一部のプロジェクトではBarbicanを避けたり、Barbicanへの依存が追加されるのを避けたりするために、
　独自の非公開ストレージを実装したいと考えています。
　　　○オペレータの期間をよりシンプルにするために、一部の開発者がこれを行っています。
●Barbicanの肯定意見：
　　　○Barbicanは数年前から存在しており、セキュリティ目的で監査されているだろう複数の企業に導入されています。
　　　○Barbicanに関わる技術の大部分は安全であることが証明されています。
　　　　これはOpenStackのセキュリティグループによって分析されました。
　　　○ハードウェアTPMの要件がないため、ハードウェアコストがかかりません。
　　　○いくつかのサービスはBarbicanを使用するオプションを提供していますが、要件は厳しくありません。
●Barbican問題のフィードバック：
　　　○デプロイにおいて、保証されないものに依存することが起きます。
　　　　　　・基本サービス（9）の提案はこれを助けることができます。
　　　○OpenStack固有のソリューション。一部の企業は、他のものと統合するソリューションを使用しています。
　　　　　　・Keywhiz （21）はKubernetesとその既存のシステムで動作します。
　　　○DevstackのプラグインはBarbicanを設定するだけです。実際にはそれを使用するために既存のサービスを何も構成しません。
　　　○テスト用に調整されたkeyマネージャーはありません。安全ではないので、
　　　　Barbicanのチームはこれをメンテナンスし直すことにしました。
　　　○APIの安定性バージョン2から3への変更は非推奨パスや保証なしに行われました。
　　　○トークンはユーザーに開放されています。KeystoneとBarbicanはもっと近くなる必要があります。
●Castellanはkey管理の抽象化を提供していますが、今ではBarbicanだけです。
●Rackspaceは最近Barbicanを利用可能にしました。おそらく、今はHAデプロイメントを実行する方が簡単でしょう。
●全スレッド

POST /api-wg/news

●新ガイドライン：
　　○正確なステータスコードvs後方互換性（22）
　　○ブラウザにサンプルファイルがないのを修正する（23）
●凍結のためのガイドライン：
　　○stateとstatusの使用に関するガイドラインを追加する（24）
　　○各バージョンのステータス値を明確にする（25）
　　○無効なクエリパラメータのガイドラインを追加する（26）
●レビュー中：
　　○boolean名のガイドラインを追加する（27）
　　○ページングのガイドラインを定義する（28）
　　○API機能を発見するためのガイドラインを追加する（29）
●全スレッド

R-4週（1月23～27日）のリリースカウントダウン

●フォーカス：
　　○今週はマイルストーンベースの全てのプロジェクトの機能凍結を開始します。
　　○この時点以降、機能パッチは適用されるべきではありません。
　　○PTLは例外を認めるかもしれません。
　　○一部の文字列の凍結が始まります。
　　　　　・レビューチームはユーザーが目にする文字列の変更を拒否しなければなりません。
　　○要件の凍結が開始されます。
　　　　　・重要な要件と制約の変更のみが許可されます。
●リリースタスク：
　　○すべてのクライアントライブラリに対する最終リリースとブランチ要求を準備します。
　　○リリースされていない変更に対するstableブランチを確認し、それらのリリースを準備します。
　　○マイルストーンベースのプロジェクトは、$project-release gerriグループのメンバーシップが
　　　プロジェクトリリースを最終確認するチームと同じく最新であることを保証する必要があります。
●一般的な注意事項：
　　○R-3のRC1ターゲット週は凍結後わずか1週間です。
●重要な日付：
　　○Ocata 3のマイルストーン、機能と要件の凍結がある：1月26日
　　○Ocata RC1ターゲット：2月2日
　　○Ocata最終リリース候補締め切り：2月16日
　　○Ocataのリリーススケジュールはこちら（30）
●全スレッド

※本コラムは以下のブログを意訳したものです。
引用元　
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170106/

※本コラムは原文執筆者が公式に発表しているものでなく、翻訳者が独自に意訳しているものです。

次のコラム：ユーザーグループニュースレター 2017年2月号

前のコラム：“ボス、OpenStackサミットに出席したいです”

バックナンバー一覧

運営会社	鈴与シンワート株式会社
所在地	東京都港区芝4-1-23 三田NNビル22階