20190118-josug-open stack-community-goals

OpenStack Community Goals
～これまでの状況と今後～
Akihiro Motoki
Jan 18, 2019
Japan OpenStack Users Group 41st meetup

Who am I ?
 Akihiro Motoki / 元木顕弘
– IRC: amotoki, Twitter: @ritchey98
– 以前は IPルータ、広域Ethernet装置、迷惑メールフィルタ、
OpenFlow 関連技術などの研究開発をしていました。
 OpenStack Upstream Developer
– Neutron: Core reviewer + drivers team
– Core reviewer of Horizon, OpenStack Client (OSC), I18n
– API-SIG, OpenStack SDK ...
 OpenStack Operator
– (でした、ちょっと前まで)
 日本OpenStackユーザー会
– 勉強会企画チーム、ボードメンバー

Agenda
 What’s “Community Goals” ?
 Community Goals in Past Releases
 Community Goals in Stein
 How are they identified and defined ?
 Candidates for “Train” release

What is “Community Goals”?
 OpenStack プロジェクト全体としてリリースごとに取り組むテーマ
 OpenStack 全体として一定レベルの一貫性や User Experience を
提供していく取り組み
– ユーザーやオペレーターは OpenStack を一つのプラットフォームと見ている
 当初は、プロジェクト毎の実装の差異を吸収する側面が強かったが、
最近は運用者視点でのゴール設定が行われてきている。

Community Goals in Past Releases
https://governance.openstack.org/tc/goals/index.html#release-cycles
 Ocata
– Remove Copies of Incubated Oslo Code
 Pike
– Control Plane API endpoints deployment via WSGI
– Support Python 3.5
 Queens
– Register and Document Policy in Code
– Split Tempest Plugins into Separate Repos/Projects
 Rocky
– Enable mutable configuration
– Remove use of mox/mox3 testing

API endpoints with WSGI
 WSGI = Web Server Gateway Interface
– Python で Web Server とアプリケーションを接続するための標準的なインターフェース
 WSGI 対応とすることで、通常のウェブサーバー側の機能を活用し
て、API サーバーを提供できる。
– これまでは eventlet を使った実装のみだった
– 様々な Web Server を使って API エンドポイントを提供できる
– Apache だと mod-wsgi モジュールを使う
 コア機能ではほとんどが対応
– Nova, Cinder, Keystone, Glance, Placement
– Neutron は Rocky で対応 (experimental)

$ ¥ls -1 /etc/apache2/sites-enabled/
cinder-wsgi.conf
glance-wsgi-api.conf
horizon.conf
keystone-wsgi-admin.conf
keystone-wsgi-public.conf
nova-api-wsgi.conf
placement-api.conf
static.conf
$ less /etc/apache2/sites-enabled/nova-api-wsgi.conf
ProxyPass "/compute" "unix:/var/run/uwsgi/nova-api-wsgi.socket|uwsgi://uwsgi-uds-nova-api-wsgi/"
retry=0
$ ps auxw | grep nova-api
tipica 5730 0.0 0.1 100384 14048 ? Ss Jan17 0:04 nova-api-metauWSGI master
tipica 5732 0.0 1.3 304788 108120 ? S Jan17 0:02 nova-api-metauWSGI worker 1
tipica 5733 0.0 1.3 305772 109076 ? S Jan17 0:02 nova-api-metauWSGI worker 2
tipica 5734 0.0 0.0 100384 4900 ? S Jan17 0:00 nova-api-metauWSGI http 1
tipica 22563 0.0 0.0 16576 2052 pts/0 S+ 13:46 0:00 grep --color=auto nova-api
tipica 26485 0.0 0.1 100384 14044 ? Ss Jan17 0:04 nova-apiuWSGI master
tipica 26487 0.0 1.6 337656 134944 ? S Jan17 0:08 nova-apiuWSGI worker 1
tipica 26488 0.0 1.6 335480 133016 ? S Jan17 0:08 nova-apiuWSGI worker 2

Policy in Code
Policy: API の RBAC (Role based Access Control) の仕組み
これまではデフォルトの policy.json で定義 (manual maintenace)
Configuration と同様に Policy もコードの中で定義
– オペレーターは差分のみを policy.json (or policy.yaml) に定義
それをベースに Policy Reference も自動生成
これに伴い ”default” ルール (fallback rule) の Cleanup が行われ、
Policy 定義がわかりやすくなった
(直接関係ないが) YAML でのポリシー定義も可能に。

Policy-in-Code (Cont.)
Nova Examples
– https://docs.openstack.org/nova/latest/configuration/policy.html
– https://docs.openstack.org/nova/latest/configuration/sample-policy.html
差分のみの定義の例
$ less /etc/neutron/policy.json
{
"context_is_admin": "role:admin or user_name:neutron"
}

Community Goals for Stein
Run under Python3 by default
Support pre-upgrade checks

Stein: Python3 by default
Python2 は Jan 1, 2020 で Python Upstream で
のサポートが終了する。
OpenStack としてもそれまでに Python3 で完全に
動作するようにしていく方針
Stein サイクルでは integration tests, functional
tests, unit tests を python3 で動かすようにする
– Python2 のテストも必要なものについては残る
– DevStack も USE_PYTHON3 のオプションが追加。
– 多くのプロジェクトが DevStack で Python3 で動作中

Stein: pre-upgrade check
アップグレード時の注意点をチェックするツール
これまでは Release Notes の Upgrade や Deprecation
をオペレーターがチェックするしかなかった。
機械的にチェックする仕組みがほしい
例: nova-status
– https://github.com/openstack/nova/blob/master/nova/c
md/status.py

How are they identified and defined?
 Summit の Forum で議論
– 項目の頭出し
– Developer & Operator からのフィードバック
 次の開発サイクル開始までの間で具体化
 前の開発サイクルの終盤に Technical Committee 主導で、次のサ
イクルのテーマを決定
 当初は Developer 主導のテーマが多かった
 Forum での議論の中で Operator に見えるテーマをもっと設定して
ほしいという要望があり、Operator にメリットのあるテーマが設定
されるようになって来ている。

Candidates for “Train” release
Berlin Smmit での議論
– https://etherpad.openstack.org/p/BER-t-series-goals
人気があったもの
– Project Resource Deletion
– Finish moving legacy python-*client to python-
openstackclient
– Ensure all projects pass project-id
 + Ensure all projects use “service-token” when calling one
another API with incoming token

“Train” release
 https://docs.openstack.org/install-guide/common/glossary.html#term-train
Train
The code name for the twentieth release of OpenStack. The OpenStack Infrastructure Summit will take place in
Denver, Colorado, US.
Two Project Team Gathering meetings in Denver were held at a hotel next to the train line from downtown to the
airport. The crossing signals there had some sort of malfunction in the past causing them to not stop the cars when
a train was coming properly. As a result the trains were required to blow their horns when passing through that area.
Obviously staying in a hotel, by trains that are blowing their horns 24/7 was less than ideal. As a result, many jokes
popped up about Denver and trains - and thus the release is called train.
OpenStack の 20 番目のリリースのコード名。 OpenStack Infrastructure サミットは、アメリカのコロラド州デ
ンバーで開催予定である。
デンバーでの 2 回の Project Team Gathering (PTG) は、ダウンタウンと空港を結ぶ電車の路線のすぐ横の
ホテルで開催された。そこの踏切の信号機は以前はイカれていて、電車が来たときでも車が適切に停止しな
い状態だった。そのため、電車はそこを通過する際に汽笛をけたたましく鳴らす必要性に迫られた。想像に難
くないが、24時間年中無休で汽笛を鳴らし続ける電車のおかげで、ホテルでの滞在は理想的とは言い難いも
のだった。その結果、デンバーと電車に関するジョークがたくさん生まれ、このリリースは Train と呼ばれること
になった。

20190118-josug-open stack-community-goals

More Related Content

Similar to 20190118-josug-open stack-community-goals

More from Akihiro Motoki

20190118-josug-open stack-community-goals