IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

OpenStack海外動向

CTC 教育サービス

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

第1回 OpenStack開発者メーリングリストの要約 10月8日〜10月14日分 2017年2月

こんにちはー。野田貴子です。

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

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

SuccessBotより
  • loquacities: Newtonのドキュメントがdocs.openstack.orgで見られるようになりました!グッジョブ、ドキュメントチーム \^o^/
  • dhellmann: OpenStack Newtonが公式にリリースされました!
  • tristanC: 次のバージョンOcataに向けて、6名がTCメンバーに選出されました[1]
  • dulek: Cinderゲートでは今、基本的なローリングアップグレードのサポートの採決を取っています。assert:supports-rolling-upgradeタグの獲得に一歩近付きました。^_^

  • もっと読む
TC(テクニカル・コミッティー)の選出方法に関する考察

・立候補すると決めた候補者は、自分がTCを務めたいと考える理由について熟考したエッセイを書く。

・補足的な質問をする機会や、自身の姿勢を決定的に説明するために他の候補者に挑戦する機会はほとんどない。
・数名の人たちがよく知られている名前をピックアップするだけで、彼らの立候補メッセージは読まれない。
・大きなプロジェクトのPTL(プロジェクト・チーム・リード)になったことがない人はまず選出されることがないと信じられている。
・暗黙のバイアスの例として、音楽オーケストラで見えないオーディションを行うと、選択結果が根本的に変わる[2]

・提案:候補者にセルフノミネートさせる。ただし長文の立候補メッセージの代わりに、務めへの興味についてをただ述べてもらう。

・ノミネートが締め切られたら、選挙役員はそれぞれの候補者を個人が特定できない形にアサインする。(例えばランダムナンバーを振る)
・候補者は自分の考えや姿勢を投稿し、人々からの質問に回答する。
・立候補エッセイはノミネート期間ではなく、選挙期間中に投稿する。
・できれば候補者は自分の返答を選挙役員に転送できるようにし、選挙役員はそれらを代わりに投稿し、候補者ナンバーのみで判別できるようにする。
・投票フォームは候補者ナンバーのみを一覧化する。

・提案に対する考察

・人物を判断できないようにしてしまうと、不正なインセンティブが発生する。候補者は友人に自分の番号をこっそり伝えることができる。暗黙のバイアスのせいで、これは道徳的にOKなのだと有権者は考えてしまい、その人に賛成投票しやすくなってしまう。
・候補者を特定できるようにすることは重要ではないだろうか。口で言っていることと、采配を得た時に実際にやることとの間に差がある人もいる。
・親しさは必ずしもバイアスとイコールではない。信頼もバイアスではない。
・誰が何を話しているかを知ることの必要性を表す良い例[2]がそのスレッドから出てきた。他にはリーダーの匿名選挙は良くない案である理由や、ネイティブ英語話者が好まれる理由についての例も。

・必要事項

・ノミネートと投票の間に時間を与えられるようにする。最終日やその前日まで立候補を表明しない人がいる。これでは彼らを知る時間が十分にない。
・タイムゾーンの違いをどう取り扱うか。ある候補者は回答を早く投稿し、より多くのリアクションを得ることができる。
・現職効果(現職が同じ派閥の候補者に与える影響のこと)を減らす。

・オーケストラのオーディションとの比較は数サイクル前にも同様に持ち出されたが、悪い比較になったようだ。彼らに求められていた仕事は楽器の演奏だったが、楽器の演奏とは関係のない多くのものが結果をバイアスしていたと判明した。

・TCの仕事とは

・心にOpenStackへの最大の興味を置くこと
・物事を終わらせるために、我々のコミュニティに集まっている多様な仲間と働くことに効率的であること。
・意見が一致しない領域を見つけそれらを減らすこと。
・コミュニティが受け入れたプロジェクト全体の目標を設定するのを手伝うこと。

・良い立候補メールを書くことは、これらの能力を上手に代弁しているわけではない。それは良い立候補メールを、英語で書くことについての評価でしかない。

・Sean Dagueは有権者が選挙で投票するとき、各候補者の評判を考慮していることを望んでいる。

・OpenStack全体を通じて彼らが行なった作業を見ること。
・どのように彼らはそれらのコンセンサスを得たのか。
・どんな努力で彼らは仲間を集め進んできたのか。
・いつ彼らは行き詰まって、いつ行き詰まらないのか。
・いつ彼らはヘルプを頼み、不得手を認めるのか。
・どのように彼らは新しい仲間を手助けするのか。
・どのように彼らは在任期間の長い仲間と作業をするのか。
・これを人気投票だと否定するのは簡単だが、しかしこれは各候補者が提出したもっともらしい誓約を評価することなのだ。彼らが抱いている考えだけではなく、どのくらい彼らはそれらを成就させることができそうかということを。

全スレッド

APIワークグループのニュース

・APIのユーザビリティテストがバルセロナサミットで実施されている[3]
・この二つは活気があるディスカッション[4]

・OpenStackを通じてエラーメッセージを収集し改良すること
・GETとbody処理に関するリクエストセマンティクス

・新しいガイドライン:

・JSONが想定されていることについての警告を追加[5]

・ガイドラインは現在レビュー中:

・時間間隔をベースにしたクエリのフィルタリングを設定する[6]

全スレッド

Ops(Operations)から見たプロジェクト・チーム・ギャザリング(PTG)

・最初のPTGはジョージア州アトランタのダウンタウンシェラトンホテルで2月20~24日に開催される。
・チケットは100ドル。
・団体割引は一晩185ドル。
・登録は2、3週間のうちに実行される。
・水平型/クロス型のプロジェクトチームが月曜と火曜に会合する予定。
・垂直型のプロジェクトは水曜から金曜に会合する予定。
・PTG計画周りでは大量の素晴らしい計画が発生しているが、オペレーターがそれを把握するにはもう少し時間がかかる。
・Tom Fifieldが提示したオペレーターへのメモ。

・PTGサイトにある図を確認すること[7]

・我々はついにリリースサイクルが計画に端を発することを認める。いま我々は一つのリリースを終えつつある一方で、また別のリリースを計画している。
・ユーザーからフィードバックや妥当な意見を得るために、サミットをこの図の中で正しい時期に設定できる。

・OpenStackットはサミコミュニティ全体が一緒になれる場所。

・サミットがマーケティングのものになることをPTGは意味していない。サミットは以下も含む:

・事前に特定されたブレインストーミング
・ユーザーとのフィードバック
・戦略的な運営に参加すること

・PTGではOpsを期待しないこと

・PTGは物事を達成するための場所を提供するために設計されている。コードを突き詰めていない限り、ユーザーは参加しない。ユーザーからフィードバックを得たいならば、サミットを利用しよう。

・KollaのようなOpsがフォーカスしているチームにとって、OpenStackサミットやOpsミッドサイクル(一種の中間会合)に参加することは不可欠。しかし全員がすべてのイベントに行かなければならないわけではない。これらのチームは誰がどのイベントに行くかを計画するべき。
・もしバルセロナで開かれるサミットに行くつもりならば、OpenStack Foundation のThierryとErinがPTGのプレゼンテーションで情報を伝える予定[8]

全スレッド

PTL(プロジェクト・チーム・リード)とTC(テクニカル・コミッティー)の次回選挙のタイムフレーム

・前回のTCミーティングでTCメンバーは今後の選挙期間について話し合った。選挙期間はOpenStackサミットやプロジェクト・チーム・ギャザリングを考慮する。
・"Design Summit"と"Summit"を交互に用いるTCの特権はもはや有効ではなく、変更が求められている。

・Foundationの規則を変更する必要を避けるために、影響する変更を制限することに対する関心があった[9]
・PTL選挙は開発サイクルの境界あたりに計画していこう。
・TC選挙はOpenStackサミットの開催日に関連して計画していこう。

全スレッド

DevstackでないジョブをPythonプロジェクトで実行

・DevstackはCI環境でOpenStackをデプロイするための共通ツール。

・しかしこれはKolla、Fuel、TripleOといったツールに対して製品環境でOpenStackをデプロイしない。

・Devstack外でOpenStackをデプロイすると、何かが壊れる(壊れた)かもしれない:

・SSLは未試験。SSLを有効化して試験していないプロジェクトがまだある。
・IPv6はどこでも試験していない。
・HA(HAproxyおよび/もしくはPacemaker)を使った製品シナリオは試験していない。

・提案:

・これはDevstackの削除についてではない。インタラクティブな方法で対象範囲を追加するというのが案だ。
・TripleOやHeatのようなプロジェクトがCIジョブとして試験的なパイプラインに追加されてきた。
・異なるプロジェクトで対象範囲を増やすことについてのドキュメントの下書き[10]

・十分に試験することと、インフラリソースの過使用の間のバランスを取ることは厄介な問題。

・また単体試験より複雑なものは0%より高い確率で失敗する危険がある。

・別の提案:

・定期的な試験を実施し、試験が合格したら参照用のハッシュを毎日次へ進める。

・自動的に次に進むために、デプロイツールを許可する。
・マスターのすぐ近くだが、すべての変更にはきつく連動しない。
・これはほとんどOpenStack-Ansibleプロジェクトが"integrated build"のためにやること。

全スレッド

 

[1] - http://lists.openstack.org/pipermail/openstack-dev/2016-October/105299.html
[2] - http://blog.leafe.com/bias/
[3] - https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21
[4] - http://eavesdrop.openstack.org/meetings/api_wg/
[5] - https://review.openstack.org/#/c/364460/
[6] - https://review.openstack.org/#/c/383862/
[7] - https://www.openstack.org/ptg
[8] - https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17383/project-teams-gathering-101
[9] - https://review.openstack.org/#/c/385951/
[10] - https://docs.google.com/spreadsheets/d/1bLg-uEGrQXyRZ-FuR6pf1WT4XN0-6MrlfqEShI7xMxg/edit#gid=0

 

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

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

 


 

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