コラム

CTC教育サービス・ホーム　＞　コラム　＞　OpenStack海外動向　＞　第2回　OpenStack開発者メーリングリストの要約 11月5日〜11月18日分

OpenStack海外動向

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第2回　OpenStack開発者メーリングリストの要約 11月5日〜11月18日分 (野田貴子) 2017年5月

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

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

SuccessBotより

mriedem: Ocata CIジョブではデフォルトでneutronを動かすようにしました。 [1]
stevemar: fernet トークン形式は今keystoneでデフォルト形式になりました。この実現にあたり、lbragstad samueldmq とdolphmに感謝します！
Ajaegar: developer.openstack.orgがOpenStackインフラでホストされるようになりました。
Tonyb: pypi [2]のOpenStack requirementsが実現しました！

プロジェクト・チーム・ギャザリングへの登録開始

・既存のアップストリームチームのメンバーを対象にした、第一回OpenStackプロジェクト・チーム・ギャザリングのイベントでは、Pikeリリースのために各プロジェクトチームが集い、開発業務について議論・整理するための会場を提供します。

・場所: ジョージア州アトランタ
・月日: 2017年2月20日の週
・登録と詳細情報 [3]
・質問がある場合はFAQをお読みください。質問が解決しない場合は、IRCのfreenodeでThierry (ttx)に問い合わせるか、設立メンバー（ptg@openstack.org）にメールしてください。

全スレッド

バルセロナ・レビュー・ケイデンス・ディスカッションの補足事項

・懸念事項を一言で言うと、Novaは複雑なものだということです。全容をきちんと知っている人はほとんどいません。
・Novaの中には高くつくミスを含む箇所があり、それらは後々の修正が困難です。
・大量のコードが素早くマージされません。
・Novaコアに対する参入障壁がとても高くなっています。
・サブシステム維持モデルが提案されました。 [4]
・一定の人たちが、良いコードをすぐにマージしてみる試みをもう一度試す価値があると確信しています。
・現在Novaは今日の様々な変更を承認するために専門家のリスト [5] を使用しています。
・NovaのPTLであるMatt Riedemannの見解：

・NovaとLinuxカーネルがひっきりなしに比較されることは好きではありません。そうではなく、OpenStackすべてがLinuxカーネルで、サブシステムはNova、Cinder、Glanceなどにあたるのです。
・言われているほどNovaコアの壁は高くありません。

・関与
・メンテナンス
・問題の所有と解決への意欲。
・役に立つコードレビュー。

・良いコードとは主観的な評価です。価値のある有用な変更は、実際にはシステムの他の部分を破壊する可能性があります。

・NovaのコアであるJay Pipesはサブシステムの提案を支持していますが、総レビュー負荷、マージ速度、およびコード品質への影響を評価するためのある種の指標に関するデータを収集する必要があると考えています。

全スレッド

OpenStackでの新しい言語の採用

・テクニカル・コミッティーであるFlavio Percocoは、新しい言語を受け入れる前にコミュニティが知っておくべきこと/しなければならないことのリストを提案しています。

・言語を使ってプロジェクトのコード/ライブラリを共有する方法を定義する

・オペレータの機能を同等に保つことが非常に重要な部分です。
・例えばOslo.configの設定ファイルは、別の言語を実装するために変更すべきではありません。
・Keystone authを使用するとカタログを介してより多くのサービス間のやりとりを行うので、オペレータが直接構成する必要がある数を減らすことができます。
・oslo.logのロギングは他のものと同じ場所に同じフォーマットでルーティングされます。
・oslo.messagingとoslo.dbも同様

・OpenStackベースのサービスのためにライブラリの基本セットを扱う
・成果物の配布方法を定義する
・メンテナンスがどの程度安定するかを定義する
・新しい言語用のCIパイプラインをセットアップする

・ゲートのキャッシング/ミラーリングと要件定義。

・これより長いバージョン。 [6]

・課題を解決するためにGolangの議論が始まった時に得られたメモ。 [7]
・TCメンバーであるThierry Carrezの発言によると、Goの導入において最も重要なことは、言語の導入でコミュニティの一部を別のものにするのではなく、これによってコミュニティが一つになるべきだということです。
・TCメンバーのFlavio Percocoによると、コミュニティ全体の懸案事項の一つとして、これらの評価が実際には完了せず不十分であることと、最前線の作業不足による懸念が生じています。その懸念はこのスレッドで対処しようとしています。
・TCメンバーのDoug Hellmannは、SwiftにGoが必要なことを見せるだけでなく、Goの採用においてSwiftがコミュニティの残りの部分を喜んで支援していることを証明することを要望しています。

・現在のバージョンのSwiftでoslo.configをどのように使用できるかについて議論をしているなど、その兆しが見られます。
・Flavioは自分の投稿とスレッドからのフィードバックを文書化したパッチを始めました。[8]

全スレッド

APIワーキンググループのニュース

・最近マージされたガイドライン：

・なぜCRUDが良いデスクリプターではないかを明確にする [9]
・複雑なクエリのためのガイドラインを追加する [10]
・フィルタリングクエリに基づいた時間間隔を指定する[11]

・現在審査中のガイドライン：

・ページングのガイドラインを定義する[12]
・WIP API性能発見ガイドライン [13]
・フィルタガイドラインに"not in"の演算子を追加する[14]

全スレッド

OakTree
～扱いやすいエンドユーザー指向のAPIレイヤ～

・ステージで見られたInterop ChallengeのOpenStackサミットの結果は素晴らしいものでした。17種類のクラウドから17名の人が同じワークロードを実行したのです！
・これが成功した理由の1つは、Shadeライブラリに基づいて我々が書いたAnsibleモジュールを全員が使用したことです。

・Shadeにはクラウドのベンダーごとの違いを隠すために必要なビジネスロジックが含まれています。
・これはOpenStackの相互運用性が素晴らしいことを示していますが、Pythonでプログラミングする場合に限ります。

・OakTreeはShadeライブラリに基づいたOpenStack用のgRPCベースのAPOサービスです。
・OakTreeをShadeベースにすると、ビジネスロジック以外にもShadeは次のことを解釈します。

・マルチクラウドの世界
・キャッシング
・バッチ処理
・高負荷時に起こりやすいthundering herdから保護し、非常に高い負荷でも効率的に処理します。

・デプロイする人がこのAPIをクラウドに追加する際の障壁を、人的に可能な限り低くする必要があります。
・s2つのリポジトリに存在する：

・openstack/oaktree [15]
・openstack/oaktreemodel [16]

・OakTreeモデルにはProtobufの定義が含まれており、それらからPython、C ++、Goのコードを生成するためのスクリプトをビルドします。
・OakTree自体はpython OakTreeモデルとShadeに依存しています。

・現在、フレーバー、イメージ、浮動小数点のリスト化と検索が可能です。
・todo.rst のリストには、良いコミュニティ設計を必要としている主要な課題がいくつかあります。 [17]

全スレッド