OpenStackアップストリーム活動実践　中級

Copyright©2019 NTT corp. All Rights Reserved.
OpenStackアップストリーム活動実践
中級
2019年7月22日（月）
夏目貴史（Takashi Natsume）
NTT ソフトウェアイノベーションセンタ
takashi.natsume.hz@hco.ntt.co.jp
（旧メールアドレス: natsume.takashi@lab.ntt.co.jp）
IRC: takashin
CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019
1F3

2Copyright©2019 NTT corp. All Rights Reserved.
• 名前
夏目貴史（なつめたかし）
• 所属
• 日本電信電話株式会社ソフトウェアイノベーションセンタ
• 業務
• OpenStackコミュニティ活動（Upstream）
• 主にNovaプロジェクトおよびその関連プロジェクトで活動
• python-novaclientのCore reviewer
• 最近はコンテナ型仮想化関連も
• Kubernetes、他。
• Observability（可観測性）について調査・検証等を行なっています。
• ブログ
• https://medium.com/@natsume.takashi
自己紹介

1. Novaのプロセス構成
2. 開発フロー
3. REST API
4. CLI
5. ドキュメント
6. テスト（Testing）
7. データベース
8. Versioned Notification
9. セキュリティ
10.Upgrade
11.ConfigオプションとPolicy
12.Backport
13.Pythonパッケージとライブラリ
14.他のプロジェクトとの連携
15.TIPS
アジェンダ

• 講演の目的
• OpenStackコミュニティに開発者としてより貢献するのに必要な
知識について説明する
• 膨大なドキュメントがある中で、開発者としてより貢献するのに
必要なドキュメントを紹介する
• ドキュメントに書かれていない、ドキュメントどおりには行かな
い事項について説明する。
• 注意事項
• Novaを中心に話しますが、他のプロジェクト（コンポーネント）
では異なる場合があります。
• Novaのソースコードを元に説明する箇所がありますが、以下のバ
ージョンを使用しています。
• masterブランチ
（commit ed49947d5acdc6435e0a76a20b8341228fbe8d27 ）
• ドキュメントについては2019年7月16日に参照した内容をベース
に説明します。
はじめに

Novaのプロセス構成

Novaを構成するプロセス
図の出典： https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#multiple-cells
複数セル構成時のnovaのプロセス構成
（デフォルトはCell1のみ（Cell0を除く）の単一セル構成）

• Filter schedulerの仕組みがあるが、Placementを利用
する方向で修正が進んでいる
• Filter schedulerの利用は縮小しており、いくつかの
Scheduling Filterが非推奨（Deprecated）になった
• Placementを呼び出す前にRequest Filterという仕組み
で、Request Specに条件を追加している（そのRequest
Specをもとに作成したResource Requestを使って
Placementに仮想サーバの配置先の候補を問い合わせる）
• nova/scheduler/request_filter.py
• 他にFlavorやImageのPropertyに設定されたtraitは
Resource Requestを作成する以下のメソッドで抽出さ
れる
• resources_from_request_spec（nova/scheduler/utils.py）
Scheduler

• Placementの呼び出しは以下のクライアントクラスで
実装されている
• nova.scheduler.client.report.SchedulerReportClient
• Placementについても理解する必要がある
• https://docs.openstack.org/placement/latest/
Scheduler （続き）

開発フロー

Novaの開発フロー
図の出典： Nova team process
（URLは次ページ）
1. REST API (Compute API)の変更はspecの作成・提出および
承認が必要
2. 機能の追加（削除）はblueprint、Bug修正はBug report
3. 機能の追加はBlueprintとspecの作成・提出および承認が
必要であるが、設計上の議論がない場合（例えば非推奨となった
機能を削除する等）はspecの提出・承認は必要ない
（不要なことはIRC Meeting等で確認する必要がある）。※
※ https://docs.openstack.org/nova/latest/contributor/blueprints.html#specs
図は次ページに続く

Novaの開発フロー
図の出典： Nova team process
https://docs.openstack.org/nova/latest/contributor/process.html

• 独立したリポジトリとなっている
（openstack/nova-specs）
• reStructuredTextで記述する(Sphinxでビルドする)
• リリースごとのテンプレートが存在するので、基本的にはそのテ
ンプレートに従い必要事項を記載してGerritでレビュー・承認し
てもらう
• Trainリリース向けspecのテンプレート
• https://specs.openstack.org/openstack/nova-
specs/specs/train/template.html
• 「specs/リリース名/approved」のディレクトリに置く
• 特に注意すべきは「Upgrade Impact」である
• NリリースとN+1リリースの共存はサポートする（ローリング・アップグ
レード可能にする）
• 過去のリリース向けに承認されたspecを再提出する場合は「
Previously-approved: リリース名」のタグをコミット・メッ
セージに入れる
• https://specs.openstack.org/openstack/nova-
specs/readme.html#previously-approved-specifications
• Compute APIの追加・変更を行なう場合は「APIImpact」の
タグをコミット・メッセージに入れる
Nova spec

Specの例
https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/cold-migration-with-target-queens.html

• 以下を参照（Trainリリースの場合）
• https://releases.openstack.org/train/schedule.html
• Novaにおいては最近の傾向として
• milestone-2(train-2)がspecフリーズ（specの承認期限）
• milestone-3(train-3)がfeatureフリーズ（機能追加のパッチ
のマージ期限）
• それ以降は基本的にBug Fixのみ
• クライアント・ライブラリ（python-novaclient）に
ついては、milestone-3でリリースを行なう
リリース・スケジュール

• Technical Committeeにより各リリースごとに設定
されるOpenStackの全体で取り組む作業項目
• 例: Python 3.5のサポート（Pike）
• TC Goalsと呼ばれることも
• 各プロジェクトにおいて強制力はない（努力目標のよう
なもの）
• https://governance.openstack.org/tc/goals/
index.html
【参考】OpenStack-wide Goals

• Chronological PTL guide
• https://docs.openstack.org/nova/latest/contributor/ptl
-guide.html
• 時系列でPTLがやるべき作業が記載されている
• Novaプロジェクトの前PTLのMelanie Wittさん作成
【参考】PTLガイド

REST API

• REST API (Compute API)を追加・変更する場合（内部の処理
ではなくインタフェース自体の追加・変更）は、まずspecを提案
する
• 追加方法（手順）
1. URLマッピングの追加（必要なら）
• nova/api/openstack/compute/routes.py
2. ポリシーの定義（必要なら）
• nova/policies以下（後述）
3. スキーマ・チェック（JSONリクエスト・ボディ、Queryパラメータ）の
追加・修正
• nova/api/openstack/compute/schemas以下
4. Controllerの追加または修正
• nova/api/openstack/compute以下
5. ユニット・テストの追加
6. Functionalテスト（APIのJSONリクエスト・ボディ、レスポンス・ボデ
ィのサンプルのためのテスト）の追加
7. ドキュメントの修正（後述）
API Reference、API Guide等
https://docs.openstack.org/nova/latest/contributor/api.html
REST APIの追加・変更

• 後方互換性(Backward compatibility)を維持するた
め、マイクロバージョンの仕組みを採用している。
• https://docs.openstack.org/nova/latest/contributor/mi
croversions.html
• どのような場合にAPIマイクロバージョンを追加する（
Bump、上げる）必要があるかは次ページを参照
API マイクロバージョン

新しいAPIマイクロバージョンの必要性の判断
図の出典：
https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion

新しいAPIマイクロバージョンの必要性の判断（続き）
以下のリストも参照
https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-
need-a-new-microversion
レスポンスにおいて以下の場合（フローチャートの記載から漏れている条件）
1. the allowed values of non free form fields
Example: adding a new allowed status to servers/{ID}
2. new headers returned on a response

• 基本的に前述したフローチャートおよびリストを基に判
断すれば良いが、議論になるケースもある
• 例：レスポンスのBodyで文字列として定義されているが、列挙
型（Enum）ではなく、単に文字列と定義されており、返却さ
れる値の種類が増えるケース
• 追加し（バージョンを上げ）ないこともできるが、追加
可能である
• 新しいAPIマイクロバージョンを追加することにより、
その機能が使用できることをユーザが認識できる
新しいAPIマイクロバージョンの追加

• OpenStack API Special Interest Group
• http://specs.openstack.org/openstack/api-
wg/index.html
• HTTP Response Codes
• REST APIのレスポンスとしてどのHTTPステータスコードを返
すべきか
• http://specs.openstack.org/openstack/api-
wg/guidelines/http/response-codes.html
REST API 追加・変更の参考情報

REST API修正（マイクロバージョン追加）の例
https://review.opendev.org/#/c/408964/
Controllerの修正
最新マイクロバージョンの更新と追加したマイクロバージョンの説明の追加
スキーマ・チェックの追加
API Referenceの修正
APIサンプルテストの追加
APIサンプルテストの追加

CLI

• APIマイクロバージョンを追加した場合、クライアント
（CLIとPython API bindings）の修正も必要になる
• python-novaclient （novaコマンド）
• python-openstackclient （openstackコマンド）
• Code Review Guide for Novaより
• A new patch for the microversion API change in python-
novaclient side should be submitted before the
microversion change in Nova is merged.
https://docs.openstack.org/nova/latest/contributor/code-
review.html#microversion-api
• python-novaclientからpython-openstackclientへの移行が
コミュニティの基本的な方針が、現在もpython-novaclientへ
の実装は必須である
CLIの追加・修正

• 追加方法のドキュメント
• Adding support for a new microversion
https://docs.openstack.org/python-
novaclient/latest/contributor/microversions.html
• 手順
1. サポートするAPIマイクロバージョンの定義の修正
2. CLIとPython APIの修正
3. 対応するテストの追加
4. CLIリファレンスの修正
5. Release noteの追加
python-novaclientへのAPIマイクロバージョン対応の追加

python-novaclientへのAPIマイクロバージョン対応の追加（続き）

• 管理者が使うツール
• Placement、Cells V2、データベース関連の操作を行なう
https://docs.openstack.org/nova/latest/cli/nova-
manage.html
• 追加・変更する場合はnova/cmd/manage.pyを修正する
• ドキュメントの更新も忘れずに
• doc/source/cli/nova-manage.rst
nova-manageコマンド

• nova-status upgrade check
• Upgradeの準備が完了しているかどうかのチェックを行なうコ
マンド
• 前提となるCinderのバージョン
• データベースのレコードの整合性
• データベースのレコードの移行が完了しているか
• ローリング・アップグレードのために必要な設定がされているか
他
• 必要であればnova/cmd/status.pyを修正してチェックを追加
する
• 参考
• ローリング・アップグレードの手順
• https://docs.openstack.org/nova/latest/user/upgrade.htm
l#rolling-upgrade-process
nova-statusコマンド

ドキュメント

• Nova doc
• End User、Operator、Contributor（Developer）向けのドキュ
メント
• doc/source以下
• 修正や追加に関連するドキュメントは更新する必要がある
• サポート・マトリックスも
• 新機能追加時は使用方法を追加することも
• API Reference
• APIマイクロバージョンの追加を行なったときは更新する
• API reference guideline
• https://docs.openstack.org/nova/latest/contributor/api-ref-
guideline.html
• API Guide
• Compute API、Novaを構成する要素の概説、用語解説等のドキ
ュメント
• api-guide/source以下
• 修正や追加に関連するドキュメントは更新する必要がある
• Release note（後述）
ドキュメントその1

• リダイレクト
• ページを移動した（パスを変更した）場合に、外部ドキュメン
トからリンクしている箇所がリンク切れになってしまう
• 移動後のページにリダイレクトさせる
• doc /source/_extra/.htaccessに対象パスとHTTPステータスコ
ード301を返すことと転送先のパスを定義する
• doc /test/redirect-tests.txtに転送の実施の確認用のテストのた
めの行を追加する
• 参考
• https://review.opendev.org/#/c /640730/
• ディレクティブ
• 以下のディレクティブを適切に使用する。
• .. todo::
• .. important::
• .. note::
• .. code-block::
• 他
※ https://docs.openstack.org/nova/latest/contributor/blueprints.htmlからの抜粋

• 他のプロジェクトのドキュメントの参照
• doc/source/conf.pyのopenstack_projectsに追加する
• stableブランチを持つプロジェクトの
ドキュメントへの参照を適切に変換してくれる。
（master→master、stable→stable）
• ファイルの中では以下のように指定する（Placementの例）
• 例 :placement-doc:`Placement <install/>`
（前略）
openstack_projects = [
'ceilometer',
'cinder',
'glance',
'horizon',
'ironic',
'keystone',
'neutron',
'nova',
'oslo.log',
'oslo.messaging',
'oslo.i18n',
'oslo.versionedobjects',
'placement',
'python-novaclient',
'python-openstackclient',
'watcher’,
]
（後略）

• Renoというツールを使用する
• https://docs.openstack.org/reno/latest/
• 使用方法
• https://docs.openstack.org/reno/latest/user/usage.html
• 生成されたファイルをgit addして、ファイルを編集して、必要なセクシ
ョンを残して必要な記述を行なう
• 追加すべき場合
• ユーザおよび運用者への影響がある事項
• Compute APIの追加・変更（APIマイクロバージョンの追加）
• CLIの変更(nova-manage、nova-status、novaコマンド等)
• コンピュート・ドライバそのものの追加、既存のものへの機能追加・変更
• セキュリティに関する修正
• アップグレードに伴う変更（configオプションの削除・移行、運用者の対応が
必要なデータベースのスキーマ変更等）
他
• https://docs.openstack.org/nova/latest/contributor/releasenote
s.html#when-a-release-note-is-needed
• 過去のRelease noteも参考にできる
• https://docs.openstack.org/releasenotes/nova/
• https://releases.openstack.org/
Release note

• OpenStack Documentation
• https://docs.openstack.org/
• 上記のURL以下にあるページから各プロジェクトのイン
ストールガイド、ユーザガイド等をリンクするための設定
やリダイレクトの有効化を行なう
• openstack/openstack-manualsプロジェクト
• www/project-data/latest.yamlで設定
（latest(master)だけでなく、各リリースごとにyamlファイルがある）
• https://docs.openstack.org/doc-contrib-guide/doc-tools/template-
generator.html#project-data-file-format
OpenStack Manuals
（前略）
- name: nova
service: Compute service
service_type: compute
has_api_ref: true
has_api_guide: true
has_install_guide: true
has_config_ref: true
has_admin_guide: true
has_user_guide: true
has_in_tree_htaccess: true
type: service
（後略）
openstack/openstack-manuals
master commit 85aed22318d1a9facd4f74133dc115060c856ae6

テスト
（Testing）

• assert文の注意点
• mockのassert文のtypoのためにチェックが正常に行われない
ケースがあるため要注意
• asset_called_once_with
• assertTrue(True, ...
• assertIsNone(None, ...
• assertEqualとすべきところをassertTrueとしている
• assertTrue(2, len(test_list))
Unit Test その1

• mockの使用
• メソッドのデコレータでmockするメソッド等を定義する
• @mock.patch(...
• @mock.patch.object(...
• テスト対象のメソッドを実行する前にmockを適用したくない
場合の対処法
• mockするメソッド等が1つの場合
• with mock.patch(... または with mock.patch.object(...
• mockするメソッド等が複数の場合
• with test.nestedの利用(nova.test.nested)
• Inner functionの利用
• 変数（定数）へのmockの適用
• 引数のnewを利用する。
• Propertyへのmockの適用
• 引数 new_callable=mock.PropertyMockを利用する
Unit Test その2
（前略）
@mock.patch('nova.db.api.service_get_minimum_version',
return_value={'nova-compute': 2})
def test_create_below_minimum(self, mock_get):
with mock.patch('nova.objects.service.SERVICE_VERSION',
new=1):
self.assertRaises(exception.ServiceTooOld,
objects.Service(context=self.context,
binary='nova-compute',
).create)
（後略）
nova/tests/unit/objects/test_service.py

Unit Test その3
（前略）
def test_start(self):
params = dict(vm_state=vm_states.STOPPED)
instance = self._create_instance_obj(params=params)
rpcapi = self.compute_api.compute_rpcapi
with test.nested(
mock.patch.object(instance, 'save'),
mock.patch.object(self.compute_api, '_record_action_start'),
mock.patch.object(rpcapi, 'start_instance')
) as (mock_inst_save, mock_record_action, mock_start_instance):
self.compute_api.start(self.context, instance)
self.assertEqual(task_states.POWERING_ON,
instance.task_state)
mock_inst_save.assert_called_once_with(expected_task_state=[None])
mock_record_action.assert_called_once_with(
self.context, instance, instance_actions.START)
mock_start_instance.assert_called_once_with(self.context,
instance)
（後略）
（前略）
def test_instance_set_to_error_on_uncaught_exception(self):
# Test that instance is set to error state when exception is raised.
instance = self._create_fake_instance_obj()
fake_network.unset_stub_network_methods(self)
@mock.patch.object(self.compute.network_api, 'allocate_for_instance',
side_effect=messaging.RemoteError())
@mock.patch.object(self.compute.network_api, 'deallocate_for_instance')
def _do_test(mock_deallocate, mock_allocate):
self.compute.build_and_run_instance(self.context, instance, {},
{}, {}, block_device_mapping=[])
instance.refresh()
self.assertEqual(vm_states.ERROR, instance.vm_state)
self.compute.terminate_instance(self.context, instance, [])
_do_test()
（後略）
with test.nestedの例
nova/tests/unit/compute/test_compute_api.py
Inner functionの例
nova/tests/unit/compute/test_compute.py

• メソッドの引数の確認
• assert_called_once_with等でメソッドの引数をチェックでき
る
• ただし、あるクラスのインスタンスで、クラスは同じでも違う
インスタンスだとチェックが失敗することがある
• 例えば、nova.context.RequestContext
• その時はnova.test.MatchTypeを使用する
• mock.ANYも使用できるが個人的にお勧めしない
Unit Test その4
（前略）
from nova import test
（中略）
@mock.patch.object(fake.FakeDriver, 'spawn')
def test_on_shared_storage_not_provided_host_with_shared_storage(self,
mock_spawn):
self.stub_out('nova.virt.fake.FakeDriver.instance_on_disk',
lambda *a, **ka: True)
self._rebuild(on_shared_storage=None)
mock_spawn.assert_called_once_with(
test.MatchType(context.RequestContext),
test.MatchType(objects.Instance),
test.MatchType(objects.ImageMeta),
mock.ANY, 'newpass', mock.ANY,
network_info=mock.ANY,
block_device_info=mock.ANY)
（後略）
nova/tests/unit/compute/test_compute.py

• コードの記述方法（スタイル）のガイドラインが存在す
る
• https://docs.openstack.org/hacking/latest/user/hackin
g.html
• 静的解析ルールによるチェック（後述）があるが、チェ
ックしていないものもある
• 例: importの順序
OpenStack Style Guideline

• Hacking checkの追加
• pep8(flake8)での静的チェック
• 過去にあった同じ間違いを繰り返さないためにチェックを追加
することが推奨される
• 主に正規表現でチェックを行なうが、正規表現が難しいケース
も存在する。
• 正規表現は可読性を考えることも重要
• ローカルではなく「OpenStack Hacking Style Checks」に
追加することも検討する
• https://opendev.org/openstack/hacking
静的解析ルール（Hacking Check）の追加

• ルールのドキュメントへの追加
• HACKING.rst
静的解析ルール（Hacking Check）の追加方法
- [N361] Check for usage of deprecated assertRegexpMatches and
assertNotRegexpMatches
次ページへ続く

• チェック用メソッドの追加と登録
• nova/hacking/checks.py
• 解析ルールのためのユニット・テストの追加
• nova/tests/unit/test_hacking.py
静的解析ルール（Hacking Check）の追加方法（続き）
（前略）
asse_regexpmatches = re.compile(
r"(assertRegexpMatches|assertNotRegexpMatches)¥(")
（中略）
def assert_regexpmatches(logical_line):
"""Check for usage of deprecated assertRegexpMatches/assertNotRegexpMatches
N361
"""
res = asse_regexpmatches.search(logical_line)
if res:
yield (0, "N361: assertRegex/assertNotRegex must be used instead "
"of assertRegexpMatches/assertNotRegexpMatches.")
（中略）
def factory(register):
（中略）
register(assert_regexpmatches)
（後略）
※ https://review.opendev.org/#/c/613184/

• ユニット・テストのカバレッジをで以下で取得できる
• tox –e cover
• 分岐網羅 (C1)
テストのカバレッジ

• Functional Testとは
• https://docs.openstack.org/nova/latest/contributor/testin
g.html#functional-tests
• Unit testやtempestによるOpenStackのコンポーネントが全て
デプロイされた環境へのテストでカバーされない範囲を対象とす
る
• Novaのコードに閉じたテストで、外部コンポーネント（Cinder
、Neutron、Placement等）へのアクセスはスタブを使用して、
novaプロセス間の連携を含めてテストする。
• どのような場合に追加すべきなのか
• はっきりとした基準があるわけではない。
• 必ず追加するケース
• APIマイクロバージョンの追加（APIサンプルの追加）
• Versioned Notificationの追加（Notificationサンプルの追加）
• 必要に応じて追加するケース（だいたい以下のようなケース）
• 複数セルをまたがった処理の追加・修正
• APIデータベースのスキーマ変更
• リグレッションテスト
他
Functional Test

• Fixtures
• 外部コンポーネント(Cinder、Neutron、Placement他)のスタブ
• ファイル
• nova/tests/fixtures.py
• nova/tests/functional/fixtures.py
• CinderのFixtureの追加例
Functional Test （続き）

• Tempest
• The OpenStack Integration Test Suite
• https://docs.openstack.org/tempest/latest/
• Compute APIのレスポンス・スキーマを変更した場
合にはTempestにテストを追加しなければならない
• https://docs.openstack.org/nova/latest/contributor/co
de-review.html#microversion-api
• 追加したパッチの例
Tempest

• プロジェクトごとに.zuul.yamlファイルで定義されて
いる
• ただし、ベースとなるJobはopenstack/openstack-zuul-jobs
プロジェクトやopenstack/project-configプロジェクトで定
義されている
• 例外
• masterブランチでしか実行しないJob等は
openstack/project-configプロジェクトに定義する（定義さ
れている）
• Central Config Exceptions
https://docs.openstack.org/infra/manual/creators.html#central-config-
exceptions
ジョブ（check, gate）
（前略）
- project:
name: openstack/nova
templates:
- periodic-jobs-with-oslo-master
- publish-to-pypi
- translation-jobs-master-stable
- api-guide-jobs
- api-ref-jobs
（後略）
openstack/project-configプロジェクト
zuul.d/projects.yaml
commit 69b6379e677a3e11dadbff1795c3796f015f4395

• Gerritのリンクを辿ると生成されたドキュメントが参
照できるので、そこからチェックできる。
ジョブの結果の見方
API guideのcheck jobは
build-openstack-api-guideである

データベース

• データベースは2種類ある（Nova）
• APIデータベース
• セル・データベース
• データベース関連ソースコード
• nova/db以下に存在する
• セル・データベースを参照・更新する操作の追加
• nova/db/api.pyにインタフェース（内部で処理を行なうメソッド
を呼び出すだけのメソッド）を定義する
• nova/db/sqlalchemy/api.pyに処理を行なうメソッドを追加する
• sqlalchemyを使用したSQL操作は他のメソッドを参考に実装できる
• APIデータベースの操作は主にnova/object以下にある各
オブジェクトの中に記述されている
データベースその1

• アップグレードに伴うスキーマの変更
• 削除（drop）や変更（alter）の操作（subtractive DB
migrations）は基本的に禁止されている（例外あり）
• ユニット・テストでもチェックするようになっている
• スキーマ変更の実装
• 以下のディレクトリに「数値3桁_名前.py」（例:
373_migration_uuid.py）のファイルを作成して、その中に
upgradeメソッドを実装する。「数値3桁」はそのディレクトリに
あるファイルに付いている数値のうち一番大きな数字に1を足した
ものとする(393が最大なら、394を使用する)
• セル・データベース
• nova/db/sqlalchemy/migrate_repo /versions
• APIデータベース
• nova/db/sqlalchemy/api_migrations /migrate_repo /versions
• テストも実装する
• nova/tests/unit/db/test_migrations.py
• nova/tests/functional/db/api/test_migrations.py

• アップグレードにともなうDBレコードの変換や補完、整合
性の確保の処理が必要なら、以下に処理を追加する
• オブジェクト
• オブジェクトにおいてDBテーブルから読み込む時は新旧両方に対応す
るとともに、DBテーブルへの保管を行なうときは新しい形式とする
• 変換・補完用コマンド（アップグレード時に実行）
• nova-manage db online_data_migrations
• nova/cmd/manage.pyのDbCommandsクラスのonline_migrationsに追加
https://docs.openstack.org/nova/latest/contributor/code-
review.html#database-schema
• アップグレード時に以下のコマンドでデータベースのスキー
マを変更する
• nova-manage db sync （セル・データベース）
• nova-manage api_db sync （APIデータベース）
• online_data_migrationsを含めた手順の詳細は以下を参照
• https://docs.openstack.org/nova/latest/user/upgrade.html#r
olling-upgrade-process

Versioned Notification

• Versioned Notificationとは
• Payloadの要素の追加／削除／変更に合わせてPayloadをバー
ジョン付けした通知の機能
• Legacy notificationからの変換がSteinリリースで完了した。
• Notifications in Nova
• https://docs.openstack.org/nova/latest/reference/notifica
tions.html
• Nova versioned notifications - the result of a 3 year
journey
• https://www.openstack.org/videos/summits/denver-
2019/nova-versioned-notifications-the-result-of-a-3-year-
journey
Versioned Notificationの追加その1

• 新規追加方針
• どのタイミングでどういったNotificationを出すといった決ま
りはない（以前ライブ・マイグレーションのNotificationの変
換の時に課題として認識されたがそのまま）
• 非同期の操作（HTTPステータスコード 202 Acceptedが返さ
れる操作）およびDBのレコードの変更を伴うような同期的な操
作の開始／終了（完了）時において通知が発行されるようにな
っている
Versioned Notificationの追加その2

1. Notification Payloadクラスの追加
nova/notifications/objects以下に追加する
Versioned Notificationの追加方法その1
（前略）
@nova_base.NovaObjectRegistry.register_notification
class VolumeUsagePayload(base.NotificationPayloadBase):
# Version 1.0: Initial version
VERSION = '1.0'
SCHEMA = {
'volume_id': ('vol_usage', 'volume_id'),
'project_id': ('vol_usage', 'project_id'),
'user_id': ('vol_usage', 'user_id'),
'availability_zone': ('vol_usage', 'availability_zone'),
'instance_uuid': ('vol_usage', 'instance_uuid'),
'last_refreshed': ('vol_usage', 'last_refreshed'),
'reads': ('vol_usage', 'reads'),
'read_bytes': ('vol_usage', 'read_bytes'),
'writes': ('vol_usage', 'writes'),
'write_bytes': ('vol_usage', 'write_bytes')
}
fields = {
'volume_id': fields.UUIDField(),
'project_id': fields.StringField(nullable=True),
'user_id': fields.StringField(nullable=True),
'availability_zone': fields.StringField(nullable=True),
'instance_uuid': fields.UUIDField(nullable=True),
'last_refreshed': fields.DateTimeField(nullable=True),
'reads': fields.IntegerField(),
'read_bytes': fields.IntegerField(),
'writes': fields.IntegerField(),
'write_bytes': fields.IntegerField()
}
def __init__(self, vol_usage):
super(VolumeUsagePayload, self).__init__()
self.populate_schema(vol_usage=vol_usage)
（後略）
（前略）
@base.NovaObjectRegistry.register
class VolumeUsage(base.NovaPersistentObject, base.NovaObject):
VERSION = '1.0'
fields = {
'id': fields.IntegerField(read_only=True),
'volume_id': fields.UUIDField(),
'instance_uuid': fields.UUIDField(nullable=True),
'project_id': fields.StringField(nullable=True),
'user_id': fields.StringField(nullable=True),
'availability_zone': fields.StringField(nullable=True),
'tot_last_refreshed': fields.DateTimeField(nullable=True,
read_only=True),
'tot_reads': fields.IntegerField(read_only=True),
'tot_read_bytes': fields.IntegerField(read_only=True),
'tot_writes': fields.IntegerField(read_only=True),
'tot_write_bytes': fields.IntegerField(read_only=True),
'curr_last_refreshed': fields.DateTimeField(nullable=True,
read_only=True),
'curr_reads': fields.IntegerField(),
'curr_read_bytes': fields.IntegerField(),
'curr_writes': fields.IntegerField(),
'curr_write_bytes': fields.IntegerField()
}
（後略）
nova/notifications/objects/volume.py
参考： nova/objects/volume_usage.py
populate_schemaメソッドを呼び出してObject（例ではVolumeUsageオブジェクト）の
フィールドをNotification Payloadのフィールドにセットすることができる。
例： https://review.opendev.org/#/c/580345/
参考: https://docs.openstack.org/nova/latest/reference/notifications.html#how-to-add-a-new-versioned-notification

2. Notificationクラスの追加
nova/notifications/objects以下に追加する
（Payloadと同じファイル）
（前略）
@base.notification_sample('volume-usage.json')
@nova_base.NovaObjectRegistry.register_notification
class VolumeUsageNotification(base.NotificationBase):
VERSION = '1.0'
fields = {
'payload': fields.ObjectField('VolumeUsagePayload')
}
（後略）
nova/notifications/objects/volume.py
サンプルファイルを指定してdoc/notification_samples以下にそのファイルを追加する。
（doc/notification_samples/volume-usage.json）
1.で作成したNotification Payloadクラスを指定する

3. Notificationを発行するメソッドの追加
nova/compute/utils.pyに追加
（前略）
from nova.objects import fields
（中略）
@rpc.if_notifications_enabled
def notify_about_volume_usage(context, vol_usage, host):
"""Send versioned notification about the volume usage
:param context: the request context
:param vol_usage: the volume usage object
:param host: the host emitting the notification
"""
payload = volume_notification.VolumeUsagePayload(
vol_usage=vol_usage)
notification = volume_notification.VolumeUsageNotification(
context=context,
priority=fields.NotificationPriority.INFO,
publisher=notification_base.NotificationPublisher(
host=host, source=fields.NotificationSource.COMPUTE),
event_type=notification_base.EventType(
object='volume',
action=fields.NotificationAction.USAGE),
payload=payload)
notification.emit(context)
（後略）
優先度をセット
（AUDIT, CRITICAL, DEBUG, INFO,
ERROR, WARN）
Notificationを発行するNovaのプロセスをセット
(API, COMPUTE, CONDUCTOR,
SCHEDULER, 他)
Actionをセット
(UPDATE, DELETE, CREATE, 他)
phaseがある場合は、phaseをセット
（START, END, ERROR）
phase=fields.NotificationPhase.START
configオプションでversioned notificationが
有効になっていなければ
メソッドの実行をスキップする。
必ず追加する。
nova/compute/utils.py

4. Notificationを発行するメソッド(3.)を対象操作（
処理）に入れる
（前略）
def _notify_volume_usage_detach(self, context, instance, bdm):
（中略）
vol_usage = objects.VolumeUsage(context)
vol_usage.volume_id = bdm.volume_id
vol_usage.instance_uuid = instance.uuid
vol_usage.project_id = instance.project_id
vol_usage.user_id = instance.user_id
vol_usage.availability_zone = instance.availability_zone
vol_usage.curr_reads = rd_req
vol_usage.curr_read_bytes = rd_bytes
vol_usage.curr_writes = wr_req
vol_usage.curr_write_bytes = wr_bytes
vol_usage.save(update_totals=True)
（中略）
compute_utils.notify_about_volume_usage(context, vol_usage, self.host)
（後略）
nova/compute/manager.py

5. サンプルファイルのためのFunctional Testの追加
（Unit TestとRelease noteも追加する）
（前略）
class TestVolumeUsageNotificationSample(
notification_sample_base.NotificationSampleTestBase):
（中略）
def test_volume_usage_with_detaching_volume(self):
server = self._setup_server_with_volume_attached()
self.api.delete_server_volume(server['id'],
self.cinder.SWAP_OLD_VOL)
self._wait_for_notification('instance.volume_detach.end')
# 0. volume_detach-start
# 1. volume.usage
# 2. volume_detach-end
self.assertEqual(3, len(fake_notifier.VERSIONED_NOTIFICATIONS))
self._verify_notification(
'volume-usage',
replacements={'instance_uuid': server['id']},
actual=fake_notifier.VERSIONED_NOTIFICATIONS[1])
（後略）
nova/tests/functional/notification_sample_tests/test_volume.py
doc/notification_samples/volume-usage.jsonを指定

セキュリティ

• ログやノーティフィケーションの出力
• センシティブな情報（パスワード等）はマスクする
• oslo.uitlsのoslo_utils.strutils.mask_passwordを利用してマス
クする
• 特定のキーを持つDictを文字列にしたものを対象に置換を行なう
• 以下（oslo.utilsのmaster）を参照
https://opendev.org/openstack/oslo.utils/src /commit/3ed4676f93996b
9f1d81a2826020d0c8cead4425/oslo_utils/strutils.py#L58-L62
• Fixの例
• あるいはそもそも出力しない
• Fixの例
• データベースやメッセージング・ミドルウェアへの接続用URI（文
字列）は要注意
セキュリティ

• セキュリティを確保するための仕組み
• 限られたコマンドしかroot権限で実行できないようにする
• 例：ファイルシステム関連（mount、mkfs等）
• 以前はroot.wrapsという仕組みだったが、privsepに置
き換えられる（Novaでは現在進行中）
• oslo.privsepというライブラリが用意されている
• nova/privsep以下にコマンド（
oslo_concurrency.processutils.execute等）の呼び
出しが集約されている
• 参考ドキュメント
• Spec
• https://specs.openstack.org/openstack/oslo-
specs/specs/liberty/privsep.html
• 使用方法
• https://docs.openstack.org/oslo.privsep/latest/user/index.
html
• プロジェクトへの新規追加方法（ブログ）
• https://www.madebymikal.com/adding-oslo-privsep-to-a-
new-project-a-worked-example/
Privsep (Privilege Separation Daemon)

Upgrade

• oslo.versionedobjects
• https://docs.openstack.org/oslo.versionedobjects/lates
t/
• オブジェクト
• 仮想サーバ（Instance）、フレーバ（Flavor）などが持つ属性
と操作（状態変更、DBの更新等）を1つのクラスにまとめて（
オブジェクトとして）扱っている
• oslo.versionedobjectsの
oslo_versionedobjects.base.VersionedObjectを継承する
オブジェクトを利用（基底クラスとしてNovaObjectクラスが
定義されている）
• ローリング・アップグレードの際に異なるバージョン（
NとN+1）のnovaプロセスが稼働することに対応させ
るためバージョン付けされている
oslo.versionedobjects

• オブジェクトへの属性・操作（メソッド）の追加・変更
• 基本的に以下の場合はバージョンを上げなければならない（ただし
例外あり）
• リモータブルなメソッドの追加・変更
• @base.remotable
• @base.remotable_classmethod
• 属性（フィールド）の追加・変更
• obj_make_compatibleの実装
• lazy-loadableなフィールドを追加したなら、obj_load_attrメソ
ッドの実装
• 他にも修正が必要
• テストの対応
• 上記の変更を行なった場合は、オブジェクトのハッシュ値（
Signature）が変更される
• ハッシュ値（とバージョン）をテストに反映させる
• nova/tests/unit/objects/test_objects.pyの「object_data」を更
新する
• 参考
• https://docs.openstack.org/nova/latest/contributor/code-
review.html#object-versions
oslo.versionedobjects （続き）

• Novaのプロセス間の呼び出し
• メッセージング・ミドルウェア（RabbitMQ等）を利用したプロセ
ス間の呼び出し
• call（返答を待つ＝同期）とcast（一方通行＝非同期）の2種類が
ある
• RPCにはバージョンが存在する
• ローリング・アップグレードのため（NとN+1バージョンの同時稼
働のため）
• Managerのメソッド自体の追加、メソッドのシグネチャの変更が
あった場合は、マイナー・バージョンを上げる
（Managerのメソッド自体を削除する場合はメジャー・バージョ
ンを上げる）
• RPC APIに後方互換性の処理を入れる
• can_send_versionで送信可能なバージョンをチェックして後方互換
性の処理を入れる
• Manager（要求を受ける側、各プロセス（nova-conductor、
nova-scheduler、nova-compute等））
• 各クラスにおいてmessaging.Targetで対応しているバージョンが定
義されている
• 例: target = messaging.Target(version='5.1')
RPC

• RPC関連ファイル
• RPC API
• nova/scheduler/rpcapi.py
• nova/conductor/rpcapi.py
• nova/compute/rpcapi.py
• Manager
• nova/scheduler/manager.py
• nova/conductor/manager.py
• nova/compute/manager.py
• RPCのバージョンを上げた修正の例
• https://review.opendev.org/#/c/582417/
• 参考
de-review.html#rpc-api-versions
RPC （続き）

• サービス・バージョンとは
• nova-computeがサポートしているCompute RPCのバージョ
ンやサポートしている機能を表す
• nova/objects/service.pyのSERVICE_VERSIONで定義
• どのような時に上げるのか
• Compute RPCのバージョンを上げた場合
• nova-computeにおいて機能を追加した場合
• 操作対象の仮想サーバの存在するCompute Nodeで操作可能かチ
ェックしてエラーを返す（アップグレードで異なるバージョンの
nova-computeが混在しているケースを想定）
• 例は次ページ
サービス・バージョン
（前略）
# NOTE(danms): This is the global service version counter
SERVICE_VERSION = 37
（後略）

• Compute: add support to abort queued live migration
• https://review.opendev.org /#/c /568542/
• API: add support to abort queued live migration in microversion 2.65
• https://review.opendev.org /#/c /573136/
サービス・バージョンのアップの例
（前略）
MIN_COMPUTE_ABORT_QUEUED_LIVE_MIGRATION = 34
（中略）
@profiler.trace_cls("compute_api")
class API(base.Base):
（中略）
@check_instance_lock
@check_instance_state(task_state=[task_states.MIGRATING])
def live_migrate_abort(self, context, instance, migration_id,
support_abort_in_queue=False):
"""Abort an in-progress live migration.
（中略）
if migration.status in queued_states:
service = objects.Service.get_by_compute_host(
context, instance.host)
if service.version < MIN_COMPUTE_ABORT_QUEUED_LIVE_MIGRATION:
raise exception.AbortQueuedLiveMigrationNotYetSupported(
migration_id=migration_id, status=migration.status)
allowed_states.extend(queued_states)
（後略）
nova/compute/api.py

• 非推奨
• Compute API (REST API)、Config option、Policy等
• 手順
• 非推奨とする
• Compute API
• あるマイクロバージョン以降は404 (Not Found)が返るようにする
• API Referenceに非推奨であることを明記する
• Release noteのdeprecationsセクションに記述する
• 例: https://review.opendev.org/#/q/topic:bp/deprecate-api-
proxies+status:merged
• CLI、configオプション、他
• 非推奨であることの設定（configオプションなら、deprecated_sinceや
deprecated_reason等の追加）や記述を行なう
• 非推奨であることの警告メッセージをログ等に出力させる
• ドキュメントに非推奨であることを明記する
• Release noteのdeprecationsセクションに記述する
• 次リリース以降に削除する
• 関連箇所、関連ファイルを削除する
• Release noteのupgradeセクションに記述する
• Compute APIの場合はHTTPレスポンスコード 410 (Gone)を返すよう
にする
• 例: https://review.opendev.org/#/c /582943/
（https://review.opendev.org/#/q/topic:bp/remove-nova-
network+status:merged）
非推奨の警告（Deprecation Warning）
参考： Policyのdeprecationの例

非推奨への変更の例
非推奨の設定を行なう
conf: Deprecate ‘keymap’ options https://review.opendev.org/#/c/483994/

非推奨への変更の例（続き）
警告をログに出力する

ConfigオプションとPolicy

• Configオプション（nova.confで設定するオプション
）の定義は、nova/confディレクトリ以下に集約され
ている
• 追加方法は次ページ以降
• 参考
de-review.html#config-options
Configオプションの追加・修正

Configオプションの追加その1
（前略）
from oslo_config import cfg
（中略）
zvm_opt_group = cfg.OptGroup('zvm',
title='zVM Options',
help="""
zvm options allows cloud administrator to configure related
z/VM hypervisor driver to be used within an OpenStack deployment.
zVM options are used when the compute_driver is set to use
zVM (compute_driver=zvm.ZVMDriver)
""")
zvm_opts = [
cfg.URIOpt('cloud_connector_url',
sample_default='http://zvm.example.org:8080/',
help="""
URL to be used to communicate with z/VM Cloud Connector.
"""),
cfg.StrOpt('ca_file',
default=None,
help="""
CA certificate file to be verified in httpd server with TLS enabled
A string, it must be a path to a CA bundle to use.
"""),
（中略）
]
def register_opts(conf):
conf.register_group(zvm_opt_group)
conf.register_opts(zvm_opts, group=zvm_opt_group)
def list_opts():
return {zvm_opt_group: zvm_opts}
1. nova/conf以下にファイルを追加し（必要な場合）、その中にオプションのグループとオプションを定義する。
既に適切なファイル（適切なオプションのグループ）がある場合は、その中にオプションを追加する。
オプションのグループの定義
（例はnova.confだとzvmセクションになる。）
オプションを定義する。
定義方法は以下を参照
https://docs.openstack.org/oslo.config/latest/reference/defining.html
参考: https://review.opendev.org/#/c/523387/
nova/conf/zvm.py
次ページ
tox -e genconfigでサンプルconfigファイルを出力するためのメソッド
setup.cfgの解説参照

2. 初期化（モジュールのimport）時に登録する処理の追加
nova/conf/__init__.py
（前略）
from nova.conf import zvm
（中略）
zvm.register_opts(CONF)
（後略）

3. Configオプションを使用する
nova/virt/zvm/driver.py
（前略）
from nova import conf
（中略）
CONF = conf.CONF
（中略）
class ZVMDriver(driver.ComputeDriver):
（中略）
def __init__(self, virtapi):
super(ZVMDriver, self).__init__(virtapi)
self._validate_options()
self._hypervisor = hypervisor.Hypervisor(
CONF.zvm.cloud_connector_url, ca_file=CONF.zvm.ca_file)
LOG.info("The zVM compute driver has been initialized.")
（後略）

• 定義はnova/policies以下に集約されている
• REST APIの処理のなかでcontext.can（nova.context.
RequestContextクラスのcanメソッド）を呼び出して認
可を確認している
（内部でnova/policy.pyのauthorizeメソッドを呼び出し
ている）
• authorizeメソッド内の初期化処理（initメソッドの呼び出
し）でEnforcerへのポリシー・ルールの登録が行なわれて
いる。
• 登録するポリシー・ルールの取得は
nova/policies/__init__.pyのlist_rulesメソッド（
nova.policies.list_rules）を呼び出している。
• nova/policies/base.pyに以下の定数が定義されている。
• RULE_ADMIN_OR_OWNER
• RULE_ADMIN_API
• RULE_ANY
Policyの追加・修正

1. nova/policies以下にファイルを追加し（必要な場合）、その中にポリシーを定義する。
既に適切なファイル（適切なポリシーの組）がある場合は、その中にポリシーを追加する。
Policyの追加その1
（前略）
from oslo_policy import policy
from nova.policies import base
POLICY_ROOT = 'os_compute_api:os-server-groups:%s'
server_groups_policies = [
policy.DocumentedRuleDefault(
POLICY_ROOT % 'create',
base.RULE_ADMIN_OR_OWNER,
"Create a new server group",
[
{
'path': '/os-server-groups',
'method': 'POST'
}
]
),
（中略）
]
def list_rules():
return server_groups_policies
nova/policies/server_groups.py
詳細は以下を参照のこと。
https://docs.openstack.org/oslo.policy/latest/user/usage.html#registering-policy-defaults-in-code

• ポリシーのルール一覧取得メソッドへの追加
Policyの追加その2
（前略）
from nova.policies import server_groups
（中略）
def list_rules():
return itertools.chain(
（中略）
server_groups.list_rules(),
（中略）
)
nova/policies/__init__.py

• Configファイル生成、Policyファイル生成、コマンド（プロセ
ス、例えばnova-api、nova-compute）の「エントリー・ポ
イント」（[entry_points]）他が定義されている
• console_scripts（pbr（※）によるPythonスクリプトの生成）
• oslo.config.opts
• tox –e genconfigでnova.confのサンプルを出力する時にconfigの一覧を
取得するメソッドを設定
• https://docs.openstack.org/oslo.config/latest/cli/generator.html
#defining-option-discovery-entry-points
• oslo.policy.policies
• tox –e genpolicyでpolicy.yamlのサンプルを出力する時にpolicyの一覧
を取得するメソッドを設定
• https://docs.openstack.org/oslo.policy/latest/user/usage.html#s
ample-file-generation
setup.cfg
（前略）
console_scripts =
nova-api = nova.cmd.api:main
（後略）
※ https://docs.openstack.org/pbr/latest/

Backport

• 新機能（Blueprint）は基本的にbackportしない
（Bug Fixで重要度が高いものが中心）
• 基本的にはmasterにmergeして、より新しいstable
ブランチから順にbackportする
• 例外的にstableブランチのみにパッチが提出・適用さ
れる場合がある
• Clean backportできるケースもあるが、Conflictが
発生して、そのままではbackportできないケースもあ
る
• masterでのパッチ作成時にBugの重要度から
backportの要否を検討してBackportしやすいように
作成することも重要
Stableブランチへのbackport

Commit messageの例（stable/rockyへのbackport）
Fix resetting non-persistent fields when saving obj
The 'requested_destination', 'network_metadata', 'retry' fields
in the RequestSpec object are reset when saving the object currently.
（中略）
So make them not be reset when saving the object.
Conflicts:
nova/objects/request_spec.py
nova/tests/unit/objects/test_request_spec.py
Conflicts are due to not including the following changes in rocky.
I53e5debcffd6de2b3a2ff838e7f5da33fa1a82b8
Idaed39629095f86d24a54334c699a26c218c6593
Change-Id: I2131558f0edfe603ee1e8d8bae66a3caf5182a58
Closes-Bug: #1815153
(cherry picked from commit 67d5970445818f2f245cf1b6d9d46c36fb220f04)
Conflictが起きたファイルとその理由を書く
※ https://review.opendev.org/#/c/643215/
Change-Idはmasterと同じIDとする
master、対象のstable branchよりも
新しいstable branchのcommit IDを
記載する。

Pythonパッケージとライブラリ

• 必要なPythonのパッケージ（PyPI）のバージョンを定義
• グローバルな（OpenStackプロジェクト全体の）定義が存
在する
• Requirementsプロジェクト
• https://docs.openstack.org/requirements/latest/
• https://opendev.org/openstack/requirements
• ローカル（Nova）の定義ファイル
• グローバルの定義と整合性を取る必要がある
• requirements.txt
• Novaのプロセスが稼働するのに必要なパッケージの情報を定義
• test-requirements.txt
• テストを実行するために必要なパッケージの情報を定義
• doc/requirements.txt
• ドキュメント生成に必要なパッケージの情報を定義
• lower-constraints.txt
• 必要なパッケージのバージョンの下限を定義
• 上記3つのファイルの下限に合わせて更新する
requirements

• 共通ライブラリとしてOsloがある
• oslo.utils
• oslo.config
他（数多くあります）
• 共通ライブラリを利用するように修正する
• OpenStackのプロジェクトで重複したコードを持たないように
するため
• 貢献するには
• osloのリリースを新機能をウォッチして適用できないか検討す
る
• Gerritにpushされた他のプロジェクトのパッチを参考にする
Osloの利用

Oslo利用の例

他のプロジェクトとの連携

• Novaは主に以下のプロジェクトと連携している
• Keystone
• nova/utils.pyのget_ksa_adapterメソッドに注目
他
• Placement
• （ここでは省略）
• Neutron
• nova/network/neutronv2以下
• Glance
• nova/image以下
• Cinder
• nova/volume以下
• Ironic
• nova/virt/ironic以下
• Cyborg（予定）
• Request ID
• 各プロジェクトへのクライアントからのリクエスト送信時にGlobal
Request IDをHTTPリクエストヘッダにセットする
• 参考
• https://review.opendev.org/#/q/topic:bug/1734625
他のプロジェクトの連携

TIPS

• git blame ファイルのパス
• そのファイルにある行ごとにその行を変更したCommit（
Commit ID）が分かる
• ただし、現在存在しない行（削除されてしまった行）がどの
Commitで削除されたかは分からない
• 例: git blame nova/compute/api.py
• git log -S 文字列
• 指定した文字列を含む現在存在しない行（削除されてしまった
行）がどのCommitで削除されたか見つけるために使用できる
• Sオプション
• Look for differences that change the number of occurrences of the
specified string (i.e. addition/deletion) in a file. Intended for the
scripter’s use.（man git logより）
• 文字列にマッチする行の追加や削除があったパッチを見る
Gitコマンド

• Hound(OpenStack Code Search)
• OpenStack関連プロジェクトの横断的な検索
• http://codesearch.openstack.org/
• Paste
• ログやコマンドの出力を貼り付けて使用することにより、レビ
ューのコメント作成に役立つ
• http://paste.openstack.org/
• Github
• Commit IDと行を指定してソースコードの該当箇所を示す
• 例えば
https://github.com/openstack/nova/blob/ed49947d5ac
dc6435e0a76a20b8341228fbe8d27/nova/compute/api.
py#L1794-L1808
便利ツール

• tox（tox.ini）
• bindep
• https://docs.openstack.org/infra/bindep/readme.html
• Nova固有の事項
• Compute Driver
• Cells V2
この資料にはないが理解が必要なこと

• ソースコードを読もう！
• 他の人のPatchのレビューを行なうことも推奨
• 関係する他のプロジェクトのリポジトリも覗いてみよう
（特にosloライブラリ）
• 読んでいれば見えてくるものがある
• ソースコードを書いてPatchをGerritにpushして貢献
しよう！
• そして、より高いレベルでのコミュニティへの貢献を目
指そう！
最後に

ご清聴ありがとうございました

OpenStackアップストリーム活動実践　中級

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a OpenStackアップストリーム活動実践　中級

Semelhante a OpenStackアップストリーム活動実践　中級 (20)

Mais de Takashi Natsume

Mais de Takashi Natsume (8)