2015-07-13

#OpenStack5Bday 「 OpenStack Summit の歩き方」のレポート

この 10 月に OpenStack Summit 2015 が東京で開催されることもあってにわかに熱い OpenStack 。

今日はその 5 歳の誕生日を祝うことも兼ねて行われた OpenStack Summit の歩き方というイベントに参加してきました。

日本 OpenStack ユーザ会のみなさんのやる気をひしひしと感じるとてもいいイベントだったと思います。猛暑日にもかかわらず、途中から会場も満席だったので、 OpenStack に対する注目度も高いなということも再確認できました。

ちなみに、わたしが参加してきたセッションは以下の技術トラックの 4 セッション。

13:00-13:40 Kiloリリースの概要、Libertyリリースの注目ポイント、さらにはMリリースの根拠のない予測

13:50-14:30 Summitで人・ひと・ヒト。いま熱く＆深く語ろうコンテナとNeutron DVR

14:40-15:20 OpenStack Upstream 富士通加藤智之、 NECソリューションイノベータ

15:50-16:30 コレジャナイOpenStack ～エンタプライズにおけるプライベートIaaSの実態と課題～

では、以降にいつもどおり各セッションでわたしがとってきたメモをまとめたものを公開しておきます。
※個人的なまとめも兼ねているので、すこしづつ修正をいれると思います。

Kiloリリースの概要、Libertyリリースの注目ポイント、さらにはMリリースの根拠のない予測 NEC 元木顕弘

概要：
OpenStackは半年に一度のサイクルでメジャーバージョンアップがリリースされます。5月にリリースされたKiloでどのような新しい機能が組み入れられたか、Kiloでできるようになったことは何か、を説明します。それを踏まえて、10月リリース予定のLibertyに向けて注目される動向を説明します。さらに大胆に来年春のMリリース（名前はまだ決まっていません）を無謀にも予測してみます。

OpenStack の最新動向 - Kilo, Library と Mxx にむけて -
@ritchey98
- OpenStack Developer
  - Neutron Core Developer
  - Horizon Core Developer
Kilo Release の概要 (201504 released)
- Big Tent
  - これまでの Integrated projects の仕組みでは要件が大きくなってきた
  - Big Tent という考え方に移行
  - 柔軟に OpenStack Official プロジェクトとして認めていく方向に変化
    - Mission については OpenStack wiki に書いてある
  - これまでの Project Lifecycle
    - outside project -> Incubation project -> Integrated project
      - 要件を満たすのが大変だった
  - New project under Big Tent
    - Murano
    - Magnum
    - Congress
    - Zaqar....
  - プロジェクトに認められる条件
    - OpenStack Mission にあっているか
    - 他のプロジェクトとの相互運用性
    - プロジェクト参加者が継続的かつ複数の組織からか
  - Tags
    - プロジェクトのリリース、運営方針などの状態を Tag という形で表現
  - DefCore
- Nova
  - Nova v2.1 API
    - v2.0 compativility + validations + microversion
  - NUMA
    - NUMA 対応スケジューリング
      - メモリの配置を意識したスケジューリング
    - 仮想 CPU の Pinning 対応、メモリのコアへの対応づけ
    - Large Page 対応
- Neutron
  - Vendor Plugin Decomposition
    - ベンダープラグイン/Driver はそれぞれ別リポジトリに分離
    - Juno Release 時点で 40 のベンダープラグイン、ドライバーが存在してしまっていた
  - Advanced service split
    - LBaaS, VPNaaS, FWaaS
    - 別のレポジトリに分離
  - Neutron Big Stadium
    - 大きなネットワークプロジェクトの下で開発
  - その他
    - Subnet Allocation
    - VLAN support in DVR
    - ML2 hierarchical port binding
    - Restructore of L2 agent/L3 agent
    - IPv6
    - etc...
- Cinder
  - Rolling Upgrade にむけた対応
  - 差分バックアップ
  - 暗号化バックアップ
- KeyStone
  - Identity Federation (認証連携)
    - 認証プロバイダとの連携など
  - Fernet Token
    - 認証後に発行されるトークンの種類として新しく追加になったもの
    - Keystone では DB なしでトークンを検証できるが、サイズは UUID Token とあまり変わらない
  - 階層的なプロジェクト管理
- Horizon
  - 新しいインスタンス起動画面 Beta
  - Angular JS ベースの実装が進展 / JS ベースでの開発への道筋
  - Glance メタデータ編集
- Swift
  - グローバルクラスターでのレプリケーションの改善
    - 広域でクラスターを組む場合、リージョン間でのコピー時にはコピーされるオブジェクトは一つだけになった。移動先で 2 個レプリカをもつ場合、リージョン間でコピーしたあとでリージョン内でレプリケーションをコピーするようになった。
  - Erasure Coding のベータリリース
    - 容量節約に役立つ
  - Composite Token
    - Nova, Glance などのサービスが Swift にデータを格納する際にユーザの代わりにデータを保存する機能。
- Sahara (使い勝手がだいぶ向上した印象とのこと)
  - 新しいプラグイン
    - Spark, Storm, Hadoop 2.6.0 CDH
  - イベントログ対応
  - Horizon でのガイド付きのガイドつきクラスター作成
  - VM Deployment Engine として Heat がデフォルトに
Liberty Release での注目ポイント
- Release Versionoing CHange
  - Librty relaese != 2.15.2.X
  - Liberty release からは 1 は最初の Integrated Release
    - e.g.
      - ceilometer 5.0.0
      - cinder 7.0.0
      - glance 11.0.0
      - heat 5.0.0
      - horizon 8.0.0 ...
- Nova
  - 詳細は Liberty Project Priorities で確認できる。
    - Cells v2
    - API v2.1
    - Scheduler
    - Upgrades
    - Developer Document Update
- Neutron
  - API versioning
  - Nova network migration
    - Linux Bridge の本格サポートの復活
    - Get me a network (VM 起動時に Neutron NW を自動作成する)
  - Ironic and Neutron integration
    - Ironic (Baremetal) 使用時の TEnant NW Isolation を実現する
    - Ironic から Neutron への物理情報を渡す API の定義
  - networking-foo
M Release について考えてみる
- Single NW Stack がやっと実現？！
- アップグレードがより現実的に？
  - Live Upgrade
  - Non-stop DB Schema migration
- コンテナを使ったデプロイが一般化？
- Big Tent モデルがますます進む？ openstack/xxxx とたくさんプロジェクトが多くなってしまったので。

Summitで人・ひと・ヒト。いま熱く＆深く語ろうコンテナとNeutron DVR 日立製作所西島直、日立ソリューションズ工藤雄大

概要：
"事前に待たないと部屋に入れない”、Vancouver Summitで大人気だったコンテナとNeutronについて、いま技術者が押さえておくべきポイントをお話します。コンテナについては、OpenStackがどのように取り込もうとしているのか、Magnumプロジェクトを中心に、さまざまなプロジェクトのコンテナの取り組みを紹介します。 Neutronについては、様々なセッションで中心話題のDVRについて、特にNorth-South通信がどのような仕組みで実現されているのかを掘り下げます。

コンテナの話と Neutron DVR
コンテナの話
- Introduction
  - コンテナ
    - 昔からある技術、隔離環境
    - コンテナと仮想マシンの違い
      - 同じ所：リソースの分離と割り当て
  - Docker
    - Docker はアプリケーションに関連するすべてのものをパッケージ化
    - どうやって実現しているのか？
      - Union file system(aufs, overlayfs, btrfs)
        
        RO なファイルシステムの上に書き込み可能なファイルシステムを重ねている
      - コミット
  - コンテナマネージャ
    - Kubernetes
      - Linux コンテナのクラスタを管理する
      - Google 内部で利用していた Borg というツールを簡略化したもの
      - Kubernetes 自体はオートスケーリング機能はないが GCE 上だとオートスケールや監視サービスが提供されている
    - Docker Swarm
      - Docker 社が公開した Docker コンテナのクラスタを管理するツール
      - 複数の Docker コンテナを管理する
      - リソースマネジメントとスケジューリング
    - Mesos
      - データセンタ OS というコンセプトのクラスタマネージャ
- OpenStack コンテナセッション
  - Keynote 2 日目でコンテナを大々的に取り扱った
    - OpenStack Foundation の COO Mark Collier 曰く
      - Nova は実験的なものから成熟しえい。次の Exprimental テクノロジはコンテナと Docker であり、 Nova と同じく急成長するだろう
  - Container Day なんてものまであった
    - 1 日中コンテナの話
    - Welcome to ContainerDay
    - OPenStack Magnum
    - How a team of four DevOps engineers at Pantheon run 400,000 Drupal/WordPress Site
    - Murano biring Docker and Kubernetes to OpenStack
    - ...
- OpenStack のコンテナの取り組み
  - 関連プロジェクト
    - Nova
      - LCX virt deriver for Nova
      - Nova Docker Driver
        
        Nova のハイパーバイザドライバの 1 つとして Docker を管理
        
        Havana から利用可能だったが out-of-tree になっていた
        
        再度マージされることになった
    - Heat
      - Nova Docker Driver にはいくつか欠点
        
        VM とコンテナのライフサイクルは違う
        
        Docker の機能を Nova API で触るのが難しい
      - 代替アプローチとして Heat を使用して Docker を操作する
    - Magnum
      - コンテナのオーケストレーションを提供する API サービス
      - Heat を使って Docker コンテナをデプロイする
      - 7 つのオブジェクト
        
        Container: Docker Container
        
        Pod: コンテナの集合
        
        Node: コンテナを実行する場所
        
        Service: Pod の論理集合とどこにアクセスするか
        
        Replication COntroller: テンプレから指定された Pod 数のレプリカを維持
        
        Bay: Node の集合 (Mesos の Bay のモデルも最近追加された)
        
        BayModel: Bay のテンプレート
      - How to use
        
        COE を作成する
        
        Bay を作成する
        
        Pod を作成する
      - 実態は Heat を呼び出すスクリプト群
        
        Magnum コマンドの引数を Heat API に変換
    - Murano
      - Application Catalog for OpenStack
        
        3 つの提供形態
        
        アプリケーションのパッケージ
        
        Heat Template
        
        ???
    - Kolla
      - Docker を利用して OpenStack サービスを提供する
        
        まだ Production ではない
Neutron DVR の話
- かなり細かい資料なので事前資料をみてほしいとのこと
- 外から製品を叩いて解析するのが好き（すごい）
- Neutron 関連のセッション : DVR 関連の話が多かった印象とのこと
- というわけで、 Neutron DVR Deep Dive
  - コードを読まずに Neutron DVR の構成や挙動(パケットの動き)を解析するという試み。
  - THINK IT DVR で検索すると今回の検証環境の構築手順をみれる
- まとめ
  - 仮想ルータ/分散仮想ルータの実態は Linux Namespace + OVS
    - DVR を有効にすると各サーバで同一の Linux Namespace ができるが、 OVS 側で余計なパケットを Drop している
  - Floating IP 有無でパケットの流れは大きく異る
    - 無しの場合
      - East/West 方向
        
        インスタンスが動作している Compute Node 同士で直接通信
      - North/South 方向
        
        SNAT 用 Namespace が動作している Network Server を経由
    - 有りの場合
      - East/West 方向
        
        インスタンスが動作している Compute Node 同士で直接通信
      - North/South 方向
        
        インスタンスが動作している Compute Node の FIP 用の Namespace が直接通信

OpenStack Upstream 富士通加藤智之、 NECソリューションイノベータ井川征幸、楽天牧垣秀一朗、 NEC 元木顕弘

概要：
OpenStackのUpstream開発者となるためのトレーニングがUpstream Trainingです。 OpenStack Foundationが主催して行っているトレーニングですが、日本OpenStackユーザ会ではこれを輸入し、日本人講師により日本語で行っています。本セッションでは、その内容を短時間に凝縮し、OpenStack Upstreamの開発がどう行われているかの概要を説明します。またUpstream開発の中心にいるPTLやコアデベロッパーがどのようなことをしているのか、何を考えているのか、重要視しているのか、など具体的なお話をする予定です。開発者としてグローバルに活躍したい方は必見です。

OpenStack Upstream とは？
- OSS の開発者になるための実践的なトレーニング
- 最新のソースコード、という意味
- 実際の Patch を投稿し Approve されるまでメンターがフォローする
- なぜトレーニングが必要？
  - 昔のように Patch を ML に送ればいいわけではない
  - コミュニティとの向き合い方などを説明
- Upstream なにがうれしいのか？
  - バグ Fix を Upstream にいれれば以降、メンテしなくてもよくなる
  - ほしい機能を提案し、コミュニティの力を借りて実装ができる
  - とか
- で、先週、日本でもやってみたのでそのレポート
Ref.
- OpenStack Upstream Training
OpenStack Upstream Training Essentials
- How to contribute のリンク
- Github にコードはあるが Pullrequest ベースではない
- まずリリースサイクルを知ろう
  - 半年ごとにメジャーリリース
    - 検討、議論、決定、実装
    - Feature proposal freeze
    - Feature freeze
      - Feature freeze exception という裏技も、、、
    - String freeze
    - Relase
- OpenStack プログラム
  - プログラムの単位に分かれている。
    - Nova などの単位でプログラム
- Technical Committee
  - 技術的なリーダーシップを発揮する人たち
- 新規プログラムのライフサイクル
  - プロジェクトごとにリリース時期に応じてタグがつけられるようになった
- Design Summit
  - Developer が OpenStack Summit に集まって次のリリースサイクルに向けた最終的な計画を打ち合わせる
- IRC ミーティング
  - 週一くらいでチームごとに定期的にミーティングを開催
  - ミーティングは常駐する Meetbot が記録
  - eavesdrop.openstack.org
- devstackorg
  - OpenStack の開発者向け環境構築ツール
  - 最新のソースコードから迅速に環境構築
  - 設定ファイルから利用プログラムやオプションを指定可能
- バグトラッキングは launchpad.net で。
  - あたらしい機能は Blueprint に
- gerrit workflow
  - どうやってコードをレビューしているのか？というフロー。
  - gerrit はコードレビューシステム
    - 結構、この使い方にハマるので、 Training ではこの使い方にももっと突っ込んだ説明をしてもらえる。
- Git の Commit メッセージの注意点
  - 複数の機能的な変更を混在させない
  - 新機能実装とリファクタリングを混在させない
  - 単一の巨大パッチで新機能をコミットしない
  - 解決する問題をわかりやすく説明する
    - 変更点の説明ではなく
  - コード自体をリーダブルに
- OSS 開発をするのに行動規範
  - 思いやりを持つ
  - お互いを尊敬する
  - 協調的であること
  - 賛成出来ない場合、他の人に相談する
  - 不明確な場合、支援を求める
  - 思いやり深く意見に従う
  - 選定プロセスを尊重する
OpenStack Upstream Development
- 日本の Core Reviewer な方々が普段どんな貢献の仕方をしてるかという話
- 開発をでいるだけスムーズに行うには？
  - 開発の流れ
  - レビュー観点
    - Pullrequest ではない
  - キーマンは？
    - PTL, core, ATC,,,,,,
  - コミュニケーション手段
    - mail, IRC, OpenStack Summit,,,
  - 誰がレビューしてくれるの？
    - お願いするだけでいいの？
      - レビューをしてくれる人はごくごく少数
- Core Developer, Core Reviewer?
  - コアの役割は質の高い、多くのレビュー
- Core のしごと
  - レビュー
  - 機能開発
  - バグ管理・修正
  - IRC ミーティング参加
  - Mid-Cycle Meeting
- レビュー観点
  - コミットメッセージがきちんと書かれているかがかなり重要
    - Fixed Bugs では誰もレビューしてくれない
    - Openstack git commit message でググれ
  - 1patch, 1変更になっているか
  - テストが書かれているか
- レビューでマイナス
  - スペルミスたくさん
  - 変更と関係ないことがダラダラと、、、 etc... lightingtalk 14110644802 conversion gate01
- まとめ
  - キーマンを見極めよう
  - 積極的にコミュニティに参加しよう
    - レビュー参加
    - ML, IRC,,,
  - 仲間をつくろう
    - IRC, Review, OpenStack Summit がさらに楽しくなるよ

コレジャナイOpenStack ～エンタプライズにおけるプライベートIaaSの実態と課題～ NTTデータ武田健太郎

概要：
SIという仕事をしていて、「OpenStackってなんかすごいらしい、どうなの？」という話を一般企業・団体からいただくことが多くなりました。ところが、実際にお話にいくと、「コレジャナイ感」を感じるお客様も多く見受けられます。今、ユーザがOpenStackに期待していることと、OpenStackが提案している内容には、いささかギャップがあるようです。本講演は、OpenStack Summitにおいて紹介された興味深い事例を交えつつ、日本特有の事情も考慮し、「コレジャナイOpenStack」がどうして起こるのか、それに対して、提供側/受給側の双方が何をすれば幸せになるのか、を議論します

@takedakn
すでに資料は slideshare.net/takedakn にあがっている
OpenStack あるある
- コレジャナイロボ的な
概要
- なんでコレジャナイが起こるのか？
- どうしたら避けられるのか？
- コレジャナイのあとにどうすればいいのか？
OpenStack も IaaS
- サーバ、ネットワーク、ストレージのサービス化
  - サービス化とは？
    - サービスである以上、提供者と受給者存在する
- IaaS でないものはなんなのか？
  - いわゆるサービス統合
    - サーバを集約し、サイロ化することが主目的
- インフラをサービス化するということ
  - ひとつのテナントのためにインフラサービスをやっているわけではない：提供者
  - こういうサービスだからその枠の中でやろう：受給者
  - サービス受給者側で認識した変化への追従がはやい
    - サーバ統合はその逆：相互の寄り添いと歩み寄りの世界
      - 変化への追従はその分だけ遅くなる
- Cloud に対する期待のすれ違い
マインドセットの変化：ペットと家畜
- サーバをペットとして使うのか、家畜として使うのか
  - ペット：個としてサーバを手塩にかけ高信頼なサーバを実現する
  - 家畜化：集団としてサーバを管理して、高信頼なサービスを実現する
    - 調子が悪くなれば交換する
コレジャナイの本当の要因は？
- 手段の目的化？
  - 提供者側の思考停止したバズワード便乗の責任は大きい一方、利用者の思考停止も等しく責任がある
問うべきこと
- あるべき姿
- 基盤に対して何を期待しているか
- 低コストでそーっと持ってくるでいいのか
- いまはそれでいいとして未来はどう考えるか
未来を考えてみる (どのように考えるか)
- 攻めの話をしているのか？それとも守りの話をしているのか？
- 攻めと守りは役割分担。
  - どちらの帽子をかぶっているかを考える
- 経産省の攻めの IT 活用指針
- その中で OpenStack Summit は攻めている事例が満載
  - Summit にでる意味があるということを力説
まとめ
- 攻めのIT、守りのIT それぞれに適した手段を選ぶ
- 攻めるなら、ペット感覚を脱し、サーバの家畜化を許容しよう
- それでも、コレジャナイ感を感じたときは？
  - 思考停止せず、個別最適に走らず、なにが全体最適なのかを考えよう
  - 短期の最適ではなく、中長期の最適を目指そう