【OpenStack入門】OpenStackを0から理解するためのページ！主要な新旧コマンドもまとめました。【兼OPCEL対策】

はじめに

クラウドで有名なOpenStackはまだまだ枯れてきたとまでは言えませんが、主要機能に関してはだいぶ成熟してきました。
今から始めても全然遅くない、むしろ今から始めても旬（？）な技術なので、まだな方はこのページで概要を理解していただければなと思います。
当方、バージョンはKiloからOcataまで触っております。
ところどころイメージを掴みやすくするために雑な絵がありますがご容赦下さい。
コマンドのオプションは必須オプションとよく使う（使いそう）なものだけ書きました。
バージョンによって無効なコマンドもありますのでご注意下さい。旧コマンドはmitakaバージョン、新コマンドはpikeバージョンのリファレンスを参照してまとめました。
個人的にはOPCEL(OpenStackの資格)受検勉強を兼ねてまとめました。

クラウド

まずは、そもそものクラウドについて。

パブリッククラウド

インターネットを通じて様々な企業や個人などが利用可能なパブリッククラウド事業者が提供するクラウドサービス。
サービスとしてはAWS、GCP、Azure、ECLなどが有名。

メリット

オンライン申し込みで即時利用可能。ユーザは使いたいときに使いたいだけ利用できる。
設備購入などの初期費用なし。
物理リソースの運用保守をユーザがやらなくて済む。

デメリット

クラウドサービスで障害が発生したときにユーザは自律的に原因解析や復旧作業を行うことができない（パブリッククラウド事業者からの復旧連絡を待つことしかできない）
大規模サービスで使用リソースが大きくなるとプライベートクラウドより費用がかさむ場合がある。（パブリッククラウドは何でも安いみたいな広告がありますが、常にあれが正しいとは限りません。）
機密情報などをパブリック環境に置くことになる。（認証などはもちろんあるけど）

プライベートクラウド

ハードウェアを自社に設置してリソースを専有する方式の"オンプレミス型"とクラウドプロバイダー事業者のサーバを仮想的に専有する方式の"ホステッド型"の2種類がある。ここではオンプレミス型の説明だけを扱う。
日本企業はプライベートクラウドを好む傾向がある。

メリット

独自のセキュリティポリシーを適用することができ、高度なセキュリティ環境を構築することができる。
故障発生時に自律的に復旧活動できる。
物理リソース追加が必要ない範囲であれば仮想リソースが大きくなっても費用は増えない。

デメリット

環境構築（設計、ハードウェア選定、発注、搬入、ラッキング、配線、インストールなど）のための初期導入コストがかかる。
ユーザ企業が自ら運用保守する必要がある。

ハイブリットクラウド

従来のオンプレミス、プライベートクラウド、パブリッククラウドのそれぞれのメリットデメリットを考慮した自社に適したインフラ環境。
例えば、アクセスの増加で高負荷となった場合に簡単に追加できるパブリッククラウドのリソースを優先的に使用することができる。

OpenStackとは

オープンソースで開発されているクラウド環境構築のソフトウェア群。
AWSを参考して（ぱくっ・・・）作られている。
2010年10月から"OpenStack"として正式にリリースされている。
最初のバージョン名は"Austin"で、現在は16番目の"Pike"がリリースされている。リリースごとにアルファベット順のコード名を付けることになっている。現在は、半年に一度新バージョンがリリースされている。
"OpenStack Foundation"と呼ばれる団体が中心となって運営されている。
元々はIaaS部分をメインに開発が進められていたが、最近ではPaaSやSaaS部分の開発も盛ん。
"コンポーネント"と呼ばれるOpenStackのクラウドサービスを構成する部品はプロジェクト毎に開発され、現在も増えたり減ったりしている。そのため、コンポーネント間は疎結合であり、機能としては単体でも動作する。
コンポーネントの内部は"プロセス"と呼ばれる機構によりさらに機能が分担されている。

OpenStackの操作

OpenStackの操作は基本的にHorizonによるWEB-UI(後述)かCUIで行う。
各コンポーネントの機能を理解する意味でもエンジニアはCUI操作に慣れておいたほうがよい。

CUI操作

"openstack"で統一された新コマンドと各コンポーネントの旧コマンドが存在する。現在も（少なくともOcataバージョンまでは確認済み）旧コマンドは一応使えるが、使用時に「今後使えなくなりますよー」と警告がでる。ちなみにOPCELでは新旧両方覚えなければならないorz
pythonで実装されている。
内部的には各コマンドはREST-APIリクエストを組み込んだcURLが実行されている。デバッグオプション（--debug）を付けることで実際の動きを確認できる。

openstackコマンドのhelp方法やデバッグオプション利用方法

#サブコマンド一覧
openstack help <command>

#サブコマンドパラメータ一覧
openstack help <command> <subcommand>

#デバッグオプション。デバッグログを出力しながら実行
openstack --debug <command> <subcommand>

ノード

OpenStackではクラウド環境を構成する物理マシンあるいは仮想インスタンスそれぞれに"コントローラノード"、"ネットワークノード"、"コンピュートノード"、"ストレージノード"の4種類のいずれかの役割が与えられる。

All-in-one構成

全てのノードを1つのホスト上で動作させる構成。
あくまで機能の確認などのお試し用に使われる。

マルチノード構成

各ノードを別々のホスト上で動作させる構成。
全てのノードを物理マシン上にそれぞれ構成するとか、さらにHA構成にするとか、1歩進んだお試し環境としてコントローラ兼ネットワークノード1台、コンピュートノード2台の構成にするとか用途によって構成は無数に考えられる。

OpenStackを支えるバックエンド技術

データベース

言わずと知れたデータベース。以下略。
MariaDB、MySQL、PostgreSQLなどの各種データベースが利用可能。

AMQP(Advanced Message Queuing Protocol)

メッセージングプロトコル。
コンポーネント内のプロセス間通信はほとんどAMQPを利用したRabbitMQなどのミドルウェアを利用して行っている。一部、GlanceやSwiftなどはプロセス間通信でもREST-APIを使用している。

memcached

キーバリュー形式でメモリ上にデータを格納する技術。データベース読み込み回数を減らして高速化する働きがある。
keystoneのトークン保管などに利用される。

NTP

言わずと知れたNTP。以下略。
クラウドとしてのサービスを正常に提供するためにサーバ同士が時刻同期されている必要がある。
システム内部に外部の公開NTPサーバと同期する内部用代表NTPサーバを構築し他のサーバはその代表サーバと同期するようにする。

デプロイツール

OpenStack環境構築の自動化ツール。

DevStack

簡易的なOpenStack環境を構築するデプロイツール。
最新2つまでのバージョンしかサポートされない。

local.conf(localrc)

[[ phase | config-file-name ]]のフォーマットで、"どのタイミング（phase）"で"どのコンフィグファイル(config-file-name)"をどのように変更するかを定義するファイル。

phase

pre-install・・・OpenStackパッケージインストール前
install・・・OpenStackパッケージインストール後
post-config・・・ネットワーク系プロセス実行前
extra・・・一番最後

config-file-name

/etc/nova/nova.confなど

重要ファイル

local.conf(またはlocalrc)・・・DevStackの設定を記述するファイル。最近ではlocal.confを使用するように推奨されている。
stack.sh・・・local.confがあれば読み込んでデプロイ実行するシェルスクリプト。なければデフォルト構成でデプロイ実行する。
local.sh・・・DevStack実行後に実行されるシェルスクリプト
unstack.sh・・・DevStackでデプロイした環境を停止するシェルスクリプト
rejoin-stack.sh・・・unstack.shで停止した環境を再開するシェルスクリプト
clean.sh・・・インストール済みパッケージを削除するシェルスクリプト

RDO Packstack

"RDO"はRedHat系OS上でOpenStackを動かすユーザ向けのコミュニティ。
"Packstack"はPuppetベースの簡易的なOpenStack環境を構築するデプロイツール。RHELだけでなくCentOSやFedoraでも動作する。
コンピュートノードの数を複数作成することはできるが、コントローラノードは1つしか作成できない。（HA構成は無理）
RHELでHA構成のOpenStack環境を自動構築するためには、RedHat社の提供するDirectorなどを使用する必要がある。
最新2つまでのバージョンしかサポートされない。
アンサーテキストと呼ばれるファイルにデプロイ構成（ノードのIPアドレスやインストール対象コンポーネントの指定など）を記述する。

重要コマンド

#アンサーテキストの作成
packstack --gen-answer-file <answer_file>

#アンサーテキストを指定してインストール実行
packstack --answer-file=<answer_file>

#オールインワンでインストール実行
packstack --allinone

RHOSPインストーラ

RedHat社が提供するRHOSP(RedHat OpenStack Platform)のデプロイツール。
最近ではDirectorと呼ばれている。
CUIあるいはWEB-UIにより高可用性も考慮した構成をデプロイできる。
TripleOをベースにしている。

TripleO

OpenStack On OpenStackの略。
HeatやIronicでデプロイしたOpenStack環境（アンダークラウド）を利用してOpenStack環境（オーバークラウド）をデプロイする。

Ubuntu OpenStack Installer

Canonical社が開発しているオープンソースのデプロイツール。
内部的にはJujuとMAASを利用している。
All-in-oneの場合、1つのコンテナ上に3つの仮想インスタンスを構築し、そのインスタンスにOpenStackをインストールする構成となる。
デプロイ時はインストーラの指示に従って行う。

重要ファイル

ディレクトリはopenstack-installコマンドを実行したユーザのホームディレクトリ。
charmconf.yaml(チャームと呼ばれるテンプレート)
config.yaml(コンテナチャームの設定)
juju/(Jujuの設定)

重要コマンド

#OpenStackのバージョンを指定してデプロイ
openstack-install --openstack-release <version>

#デプロイの状況確認
openstack-status

Juju/MAAS

OSとアプリケーションのデプロイをJujuで、リソースの管理をMAASで行うCanonical社製デプロイツール。
OpenStack専用のツールではない。

Juju

OSやアプリケーションのデプロイツール。
Charmとアプリケーションのインストール手順を記述する。

MAAS

物理マシンや仮想インスタンスを管理するツール。内部的にはIPMIやWake-on-LANなどが利用されている。

重要コマンド

※ここでのserviceはアプリケーションやミドルウェアのことを指す

#サービスの状況確認
juju status

#bootstrapの構成を定義するファイルの生成
juju init
juju generate-config

#デプロイ実行
juju deploy <service>

#Bootstrapの起動
juju bootstrap

#サービス間の関連付け
juju add-relation <service1> <service2>

#サービスにssh
juju ssh <service>

#サービスを外部公開
juju expose

#Juju環境削除
juju destroy-environment <environment_name>

HP Helion

HP社製のデプロイツール。
TripleOをベースにしている。

FUEL

Mirantis社製のデプロイツール。
GUIでインストールできる。

Ansible

OpenStack専用ではないですが私はこれをよく使います。

コアコンポーネント

現在約50個あるコンポーネントのうち、特に中核を担うKeystone、Glance、Neutron、Nova、Cinder、Swiftの6個のコンポーネントを"コアコンポーネント"と呼ぶ。

Keystone

認証トークンの管理とエンドポイントの管理を提供するコンポーネント。
認証トークンはmemcached上で管理する。
Keystoneのインストール直後ではユーザが登録されていないため、admin_tokenと呼ばれるkeystone.confに定義された特別なトークンを利用して管理者ユーザーをまず作成する。

プロジェクトとロールとユーザ

プロジェクトはユーザのグループのようなもの。昔は"テナント"と呼ばれていたが、最近は"プロジェクト"と呼ばれるようになった。
ロールはユーザのプロジェクト利用権限。
ユーザはロールによってプロジェクトに結び付けられることで、そのプロジェクト内のリソースにアクセスできる。

トークン管理

ユーザ/パスワードの組み合わせで指定プロジェクトへのアクセスリクエストをkeystoneに送信し、認証が成功すればトークンを取得できる。トークンがなければOpenStackの各サービスは利用できない仕組みになっている。
トークンは一定時間過ぎると期限切れになる。
HTTPの"X-Subject-Token"ヘッダーを使用してKeystoneよりトークンを取得し、"X-AUTH-Token"ヘッダーを使用してトークンを指定し、コンポーネントのREST-APIにリクエスト送信する。

環境変数ファイル

CUIでリクエストするにあたって、トークンを取得するためにいちいちユーザ情報などの環境変数を設定するのはめんどくさいので、環境変数をファイルにまとめて定義してそれを読み込む方法が一般的。
以下は環境変数ファイルの例。

admin_openrc

export OS_PROJECT_DOMAIN_ID = default 
export OS_USER_DOMAIN_ID = default 
export OS_PROJECT_NAME = admin 
export OS_TENANT_NAME = admin 
export OS_USERNAME = admin 
export OS_PASSWORD = password 
export OS_AUTH_URL = http://controller:35357/v3

policy.json

各コンポーネントのREST-API実行の制限ファイル。例えばNovaであれば/etc/nova/policy.jsonで用意される。
「"target":"rule"」フォームにより定義され、"target"は"start an instance"や"attach a volume"といったAPIコール。"rule"は権限について。

policyの例

#novaのインスタンス一覧取得APIはどのユーザでも可能とするpolicy
"compute:get_all" : "" 

#novaのインスタンス一覧取得APIはadminユーザだけ可能とするpolicy
"compute:get_all" : "role:admin"

#novaのインスタンス一覧取得APIはどのユーザも不可能とするpolicy
"compute:get_all": "!"

重要ファイル

/etc/keystone/keystone.conf
/etc/default_catalog.templates・・・エンドポイントの定義
/etc/keystone/policy.json
/var/log/keystone配下

重要コマンド

#プロジェクト一覧
keystone tenant-list
openstack project list

#プロジェクト詳細
keystone tenant-get <tenant>
openstack project show <project>

#プロジェクト作成
keystone tenant-create --name <tenant_name>
openstack project create <project_name>

#プロジェクト削除
keystone tenant-delete <tenant>
openstack project delete <project>

#プロジェクト情報更新
keystone tenant-update <tenant>
openstack project set <project>


#ユーザ一覧
keystone user-list
openstack user list

#指定プロジェクトのユーザ一覧
keystone user-list --tenant-id=<tenant_id>
openstack user list --project <project>

#ユーザ詳細
keystone user-get <user>
openstack user show <user>

#ユーザ作成
keystone user-create --name <user_name>
openstack user create <user_name>

#ユーザ削除
keystone user-delete <user>
openstack user delete <user>

#ユーザ情報更新
keystone user-update <user>
openstack user set <user>

#ユーザ（一般ユーザ）のパスワード変更
keystone user-password-update --pass <password> <user>
openstack user set --password <password> <user>


#ロール一覧
keystone role-list
openstack role list

#ロール詳細
keystone role-get <role>
openstack role show <role>

#ロール作成
keystone role-create --name <role_name>
openstack role create <role_name>

#ロール削除
keystone role-delete <role>
openstack role delete <role>


#ユーザのロール一覧
keystone user-role-list
openstack user role list

#ユーザにロールを与える
keystone user-role-add --user <user> --role <role>
openstack role add --user <user> <role>

#ユーザに与えられたロールを取り除く
keystone user-role-remove --user <user> --role <role>
openstack role remove --user <user> <role>

Glance

インスタンスのイメージやスナップショットを管理するコンポーネント。
glance-apiとglance-registryのプロセス間はAMQPを利用せずにREST-APIで連携している。

プロセス

glance-api

GlanceのREST-APIを提供し、実際にイメージの操作を行うプロセス。
イメージの保存先はglance-api.confのfilesystem_store_datadirで指定する。ローカル、Swift、AWSのS3などを指定できる。

glance-registry

イメージやスナップショットに関するメタデータ情報（名前やサイズや保存先など）をデータベースで管理するプロセス。

キャッシュ

インスタンスの起動が行われると、glance-apiが起動しているサーバーのローカルディスク上に、起動に使用されたイメージのキャッシュが保存される。キャッシュ保存時間以内であれば同じイメージで起動すると早い。
キャッシュデータを保管する場所はglance-cache.confのfilesystem_store_datadirで指定できる。デフォルトは/var/lib/glance/配下である。
キャッシュの最大値はglance-cache.confのimage_cache_max_sizeオプションで設定する。

#ローカルキャッシュの一覧
glance-cache-manage list-cached

#キャッシュ予約キューに入っているイメージのキャッシュを作成
glance-cache-prefetcher

#キャッシュの削除
glance-cache-cleaner

#キャッシュが一定サイズを超えていたら古いキャッシュを削除
glance-cache-pruner

レプリケーション

glance-replicatorコマンドによりイメージのコピーを行う機能。

#Glanceサーバ間でイメージを比較
glance-replicator compare

#ダウンロードするイメージのサイズを確認
glance-replicator size

#Glanceサーバ間でイメージをコピー
glance-replicator livecopy

#Glanceサーバからイメージをダウンロード
glance-replicator dump

#Glanceサーバへイメージをアップロード
glance-replicator load

カスタムイメージの作成

インスタンス生成に使用するイメージをユーザ独自に編集したものをカスタムイメージと呼ぶ。

イメージサイズの削減

イメージをQCOW2形式に変換してイメージサイズを削減できる。

#イメージ情報表示
qemu-img info <image>

#qcow2形式に変換
##-cでイメージサイズの削減をする
##-fで現在のフォーマットを指定する
##-Oで変換したいフォーマットを指定する
qemu-img convert -c \
-f raw \
-O qcow2 
<original_image_name> \
<formatted_image_name>

cloud-init

イメージファイルにcloud-initをインストールして、/etc/cloud/cloud.cfg(yaml形式)の設定を行っておくことで、インスタンス起動時にその設定を自動化できる。
設定内容は基本的に手動でOSインストール時に設定できる項目と同じで、例えば、rootユーザのパスワード設定、一般ユーザの作成、言語の設定、ホスト名の設定、SSH鍵の設定、必要パッケージのインストールなどである。

virt-edit

イメージのネットワークインタフェース設定（IPアドレス、MACアドレス、UUIDなど）の編集を行うコマンド。

virt-sysprep

イメージのシステム構成情報（MACアドレス、sshホストキー、ユーザーアカウントなど）を削除するコマンド。

重要ファイル

/etc/glance/glance-api.conf
/etc/glance/glance-registry.conf
/etc/glance/glance-cache.conf
/etc/glance/policy.json
/var/log/glance配下

重要コマンド

#イメージ一覧
glance image-list
openstack image list

#イメージ詳細
glance image-show <image>
openstack image show <image>

#イメージ登録
##--disk-formatでqcow2などのディスクフォーマットを指定する。
##--container-formatでbare(イメージ内にメタデータを含まない形式)などのコンテナフォーマットを指定する。
##--locationでイメージファイルのURLを指定する。ローカルに存在するイメージを使用する場合は--fileでパスを指定する。
##--is-public=Trueあるいは--visibility public(--public)でどのユーザでも使用可能にする。
glance image-create --name <image_name> \
--disk-format <disk_format> 
--container-format <container_format> \
--location <image_url> 
--is-public=True | --visibility public
openstack image create <image_name> \
--disk-format <disk_format> \
--container-format <container_format> 
--location <image_url> \
--public

#イメージ削除
glance image-delete <image>
openstack image delete <image>

#イメージ変更
glance image-update <image>
openstack image set <image>

#イメージのダウンロード
glance image-download <image>
openstack image save <image>

Neutron

仮想ネットワークサービスを提供するコンポーネント。
Linuxの名前空間機能を利用し、プロジェクト毎に独立したネットワークサービスを提供する。
Linuxのdnsmasq機能を利用し、仮想DHCPサーバ機能を提供する。
Linuxのlinux-brdige機能（あるいはOpen vSwitch）を利用し、受け取ったパケットのVLANIDから対応する仮想ルータ(プロジェクトネットワーク)にパケットをL2転送する。
Linuxのパケットフォワーディング機能とパケットフィルタリング機能（iptables）を利用し、仮想ルータ機能を提供する。

プロセス

neutron-server

NeutronのREST-APIを提供するプロセス。
neutron-serverが停止しても既に稼働中のネットワークが止まることはない。

neutron-linuxbridge-agent

linux-bridgeによるL2エージェント(L2の仮想ネットワーク機能を実現する）プロセス。
linux-bridgeは簡易的な仮想ネットワークスイッチの役割を果たす。
テナント毎に共通の仮想ブリッジを作成してその仮想ブリッジに複数のインスタンスを接続することで同一物理サーバ内かつ同一テナント内でのインスタンス間のL2通信を可能にする。
物理スイッチのVLAN機能を利用することにより、異なる物理サーバであっても同一テナント内での間のL2通信を可能にする。
冗長化の考慮は不要だがプロセス監視は必要。

neutron-openvswitch-agent

Open vSwitchによるL2エージェントプロセス。
Open vSwitchはlinux-bridgeよりも高度な仮想ネットワークスイッチの役割を果たす。
Open vSwitchにインスタンスをそれぞれブリッジ接続することで、同一物理サーバ内かつ同一テナント内でのインスタンス間のL2通信を可能にする。
物理スイッチのVLAN機能と例えばOpen vSwitchのGREトンネリング機能を組み合わせることで、異なる物理サーバであっても同一テナント内でのインスタンス間のL2通信を可能にする。
冗長化の考慮は不要だがプロセス監視は必要。

neutron-l3-agent

ルーティングやfloating-ipの割り当てを処理するL3エージェントプロセス。

neutron-dhcp-agent

インスタンスへのDHCPによるIPアドレスの払い出しを処理するプロセス。

neutron-metadata-agent

インスタンスのメタデータサーバへのアクセスを補助するプロセス。
インスタンスから"http://169.254.169.254"へアクセスすると、neutron-metadata-agentは仮想ルータ上でメタデータサーバへアクセスを中継する。

neutron-ns-metadata-proxy

neutron-metadata-agentと同様に、インスタンスのメタデータサーバへのアクセスを補助するプロセス。
neutron-metadata-agentだけでは仮想ルータが存在しない仮想ネットワーク上ではメタデータサーバへアクセスできないため、neutron-ns-metadata-proxyを仮想ネットワーク毎に起動して、neutron-metadata-agentへ中継する。

名前空間

LinuxOS上のリソースの空間（仕切り）。
名前空間を利用してプロジェクト毎に独立したネットワーク環境を提供する。
仮想ルータや仮想DHCPサーバは名前空間内に閉じて動作するため、既存ネットワークに影響を与えることなく仮想ネットワークを作成できる。

Fixed ip

インスタンスが起動する際に割り当てられる内部的なIPアドレス。名前空間上に存在する仮想DHCPサーバから払い出されるIPあるいは固定のIPがインスタンスに割り当てられる。
"Fixed"なので固定IPアドレス限定かと思いきやそうではない。

Floating ip

OpenStack環境の外部からインスタンスにアクセスするために割り当てるIPアドレス。（つまり内部から外部へはFloating ipなしで通信できる。）
インスタンスに固定のIPアドレスが割り当てられるような振る舞いをするが、実際は仮想ルータにFloating ipが割り当てられており、そこでNAT変換されている。
AWSのElastic ip相当。

Open vSwitch(OVS)

仮想ネットワークスイッチ。

#ブリッジや関連物理NICやOVSのバージョン情報の表示
ovs-vsctl show

#ブリッジの作成
ovs-vsctl add-br <bridge_name>

#ブリッジを物理NICに関連付け
ovs-vsctl add-port <bridge_name> <physical_nic_name>

#物理NICのIPを無効化
ifconfig <physical_nic_name> 0.0.0.0

#ブリッジに無効化した物理NICのIPを割り当てる
ifconfig <bridge_name> <ip>

DVR

Opne vSwitchプラグインの機能により全てのコンピュートノードに仮想ルータを配置する技術。
通常、仮想ルータはネットワークノード上に配置されるため、異なるサブネット上に存在するインスタンス同士の通信や外部との通信がネットワークノードに集中することでボトルネックになる可能性があるが、DVRはその問題を解決することができる。
代表仮想ルータがルーティングテーブルを管理し、各仮想ルータはその代表仮想ルータと同期する。

L3HA(VRRP)

複数の仮想ルータをACT-SBY方式でネットワークノードに分散配置する冗長化技術。

他の高速化技術

SR-IOVとかDPDKとかあるけど別の記事でいつかまとめたい。

トラフィックメータリング

"metering_agent.ini"ファイルのパラメータ"interface_driver"に"neutron.agent.linux.interface.BridgeInterfaceDriver"を設定することでLinux BridgeでL3のトラヒックメータリングを有効化できる。"neutron.agent.linux.interface.OVSInterfaceDriver"を設定することでOVSでL3のトラヒックメータリングを有効化できる。

仮想ネットワークタイプ

仮想ネットワークを作成する際にタイプを指定する。

• local：他のネットワークとの接続無し
• flat：vlanタグを使用しない
• vlan：vlanタグを使用する
• vxlan：トンネリングプロトコルにvxlanを使用
• gre：トンネリングプロトコルにgreを使用

重要ファイル

/etc/neutron/neutron.conf
/etc/neutron/plugin.ini（L2エージェントに関する設定ファイル）
/etc/neutron/l3_agent.ini
/etc/neutron/dhcp_agent.ini
/etc/neutron/metadata_agent.ini
/etc/neutron/plugins/ml2/ml2_conf.ini
/etc/neutron/plugins/ml2/openvswitch_agent.ini
/etc/neutron/plugins/ml2/linuxbridge_agent.ini
/etc/neutron/policy.json
/var/log/neutron配下

重要コマンド

#仮想ネットワーク一覧
neutron net-list
openstack network list

#仮想ネットワーク詳細
neutron net-show <network>
openstack network show <network>

#仮想ネットワーク作成
##--shared（--share）で異なるプロジェクトでも利用できるようにする。
##--provider:network_type（--provider-network-type）でlocal,flat,vlan,vxlan,greのいずれかのネットワークタイプを指定する。
##--provider:segmentation_id（--tag）で--provider:network_typeがvlanだった場合のVLANIDを指定する。
##--provider:physical_network（--provider-physical-network）で/etc/neutron/plugin.iniのbridge_mappingsで指定したブリッジを指定
neutron net-create --tenant-id <tenant_id> \
--shared \
--provider:network_type <network_type> \
--provider:physical_network <physical_network> \
--route:external=True <network_name> 
openstack network create --project <project> \
--share \
--provider-network-type <network_type> \
--provider-physical-network <physical_network> \
--external <network_name>

#仮想ネットワーク削除
neutron net-delete <network>
openstack network delete <network>

#仮想ネットワーク更新
neutron net-update <network>
openstack network set <network>


#仮想サブネットワーク一覧
neutron subnet-list
openstack subnet list

#仮想サブネットワーク詳細
neutron subnet-show <subnet>
openstack subnet show <subnet>

#仮想サブネットワーク作成
##--disable-dhcp(--no-dhcp)で仮想DHCP機能を利用しないことを宣言。外部ネットワークの場合は物理ネットワーク側でDHCPが用意されていることが多い。
##--alocation-poolでインスタンスに割り当てるIPアドレスの範囲を指定する。
neutron subnet-create --tenant-id <tenant_id> \
--name <subnet_name> \
--gateway <gateway> \
--disable-dhcp \
--allocation-pool start=<ip>,end=<ip> \
<network> \
<CIDR>
openstack subnet create --project <project> \
--gateway <gateway> \
--no-dhcp \
--allocation-pool start=<ip>,end=<ip> \
--network <network> \
<subnet_name>

#仮想サブネットワーク削除
neutron subnet-delete <subnet>
openstack subnet delete <subnet>

#仮想サブネットワーク更新
neutron subnet-update <subnet>
openstack subnet set <subnet>


#仮想ルータ一覧
neutron router-list
openstack router list

#仮想ルータ詳細
neutron router-show <router>
openstack router show <router>

#仮想ルータ作成
neutron router-create --tenant-id <tenant_id> <router_name>
openstack router create --project <project> <router_name>

#仮想ルータ削除
neutron router-delete <router>
openstack router delete <router>

#仮想ルータ更新
neutron router-update <router>
openstack router set <router>

#仮想ルータに接続されたポート一覧
neutron router-port-list
openstack port list --router <router>

#仮想ルータを仮想サブネットワークに接続
neutron router-interface-add <router> <subnet>
openstack router add subnet <router> <subnet>

#仮想ルータを仮想サブネットワークから切り離す
neutron router-interface-delete <router> <subnet>
openstack router remove subnet <router> <subnet>

#仮想ルータを仮想ネットワークのデフォルトゲートウェイに設定
neutron router-gateway-set <router> <network>

#仮想ルータをデフォルトゲートウェイとしての設定から外す
neutron router-gateway-clear <router>


#ポート一覧
neutron port-list
openstack port list

#ポート詳細
neutron port-show <port>
openstack port show <port>

#ポート作成
neutron port-create --tenant-id <tenant_id> \
--name <port_name> \
--mac-address <mac_address> \
<network>
openstack port create --network <network> \
--mac-address <mac-address> \
<port_name>

#ポート削除
neutron port-delete <port>
openstack port delete <port>

#ポート更新
neutron port-update <port>
openstack port set <port>


#Floating ip一覧
neutron floatingip-list 
openstack floating ip list

#Floating ip詳細
neutron floatingip-show <floating-ip>
openstack floating ip show <floating-ip>

#Floating ip作成
##--floating-ip-addressで固定のFloating ipを割り当て
neutron floatingip-create --tenant-id <tenant_id> \
--port-id <port_id> \
--floating-ip-address <ip> \
--subnet <subnet> \
<network>
openstack floating ip create --project <project> \
--port <port> \
--floating-ip-address <ip> \
--subnet <subnet> \
<network>

#Floating ip削除
neutron floatingip-delete <floating-ip>
openstack floating ip delete <floating-ip>

#Floating ipをインスタンス（ポート）に割り当てる
neutron floatingip-associate <floating-ip> <port>
openstack floating ip set --port <port> <floating-ip>

#Floating ipをインスタンス（ポート）から外す
neutron floatingip-disassociate <floating-ip>
openstack floating ip unset --port <port> <floating-ip>


#セキュリティグループ一覧
neutron security-group-list
openstack security group list

#セキュリティグループ詳細
neutron security-group-show <sg>
openstack security group show <sg>

#セキュリティグループ作成
neutorn security-group-create --tenant-id <tenant_id> <security_group_name>
openstack security group create --project <project> <security_group_name>

#セキュリティグループ削除
neutron security-group-delete <sg>
openstack security group delete <sg>

#セキュリティグループルール一覧
neutron security-group-rule-list
openstack securiyt group rule list

#セキュリティグループルール詳細
neutron security-group-rule-show <sg_rule>
openstack security group rule show <sg_rule>

#セキュリティグループルール作成
##--direction(--ingress | --egress )でingress（インバウンド）かegress（アウトバウンド）を指定する。
##--protocolで許可するパケットのプロトコルを指定。"icmp"、"tcp"やポート番号を指定できる。
##--port-range-minと--port-range-max(--dst-port)で許可ポートの範囲を指定する。
##--remote-ip-prefix(--remote-ip)で許可するインバウンドのIPを指定する。指定しなかった場合は、デフォルトで0.0.0.0/0となる。
neutron security-group-rule-create --tenant-id <tenant_id> \
--direction <ingress | egress> \
--protocol <protocol> \
--port-range-min <port> \
--port-range-max <port> \
--remote-ip-prefix <ip> \
<sg>
openstack security group rule create --project <project> \
--ingress | --egress \
--protocol <protocol> \
--dst-port <port_range> \
--remote-ip <ip>
<sg>

#セキュリティグループルール削除
neutron security-group-rule-delete <sg_rule>
openstack security group rule delete <sg_rule>

Nova

プロセス

nova-api

NovaのREST-APIを提供するプロセス。

nova-scheduler

どのコンピュートノードにインスタンスを生成するかの振り分けを行うプロセス。
スケジューリングの方式は"チャンススケジューラー"と"フィルタースケジューラー"の2種類存在する。

チャンススケジューラー

コンピュートノードをランダムに選択する方式。

フィルタースケジューラー

"フィルター"と"重み計算"の2段階の条件からコンピュートノードを選択する方式。条件に利用するデータはnova-schedulerがデータベースから取得する。
1段階目の"フィルター"では例えば、"空きメモリーの割合"や"指定アベイラビリティゾーン"（インスタンス生成の時にオプションで指定）などで条件にあうコンピュートノードを抽出する。
2段階目の"重み計算"では1段階目でのフィルターで抽出されたコンピュートノードの中で、例えばメモリーの空き容量などに基づく重み計算をし、その中で最も重みが軽いコンピュートノードを選択する。この重み計算を調整することで、分散配置でなく特定のコンピュートノードに詰めるように配置させることもできる。

nova-conductor

nova-computeがAMQPサーバに送った情報をまとめてNovaのDBに格納するプロセス。nova-computeがそれぞれDBアクセスするとアクセス負荷が高まるため、それを軽減する働きをする。

nova-compute

ハイパーバイザの制御によるインスタンスの管理を行うプロセス。KVMなどのハイパーバイザを利用してコンピュートノード上に実際にインスタンスを作成および削除する。
冗長化の考慮は不要だがプロセス監視は必要。

nova-consoleauth

nova-novncproxyあるいはnova-xvpvncproxyによるインスタンスのVNC管理画面のセッション（トークン）を管理するプロセス。

nova-novncproxy

noVNCを利用したウェブブラウザ経由のVNCアクセスを提供するプロセス。Horizonは内部ではnova-novncproxyにリクエストを送っている。

nova-xvpvncproxy

Javaの専用クライアントソフトからのVNCアクセスを提供するプロセス。

nova-cert

EC2互換APIを利用するための証明書を管理するプロセス。

重要ファイル

/etc/nova/nova.conf
/etc/nova/policy.json
/var/log/nova配下

重要コマンド

#インスタンス一覧
nova list
openstack server list

#インスタンス詳細
nova show <server>
openstack server show <server>

#インスタンス生成
nova boot --image <image> \
--flavor <flavor> \
--key-name <key_name> \
--availability-zone <availability_zone> \
--security-groups <sg_name>  \
--nic net-id=<net_id>,v4-fixed-ip=<fixed_ip_address>,port-id=<port_id> \
<server_name>
openstack server create --image <image> \
--flavor <flavor> \
--key-name <key_name> \
--availability-zone <availability_zone> \
--security-group <sg> \
--nic net-id=<net_id>,v4-fixed-ip=<fixed_ip_address>,port-id=<port_id> \
<server_name>

#インスタンス削除
nova delete <server>
openstack server delete <server>

#インスタンスにFixed ipを割り当てる
nova add-fixed-ip <server> <network>
openstack server add fixed ip <server> <network>

#インスタンスにFloating ipを割り当てる
nova floating-ip-associate <server> <ip>
openstack server add floating ip <server> <ip>

#インスタンスにセキュリティグループを割り当てる
nova add-secgroup <server> <sg>
opensack server add security group <server> <sg>


#インスタンス停止
nova stop

#インスタンス起動
nova start

#インスタンス再起動
##--hardでハード再起動
nova reboot

#レスキューモードで再起動
nova rescue

#インスタンスを通常の起動ディスクから再起動
nova unrescue

#休止（ハイパーバイザレベル）
nova suspend

#休止解除
nova resume

#一時停止（メモリにインスタンスの状態を保持）
nova pause

#一時停止解除
nova unpause


#フレーバ一覧
nova flavor-list
openstack flavor list

#フレーバ詳細
nova flavor-show
openstack flavor show

#フレーバ作成
nova flavor-create <flavor_name> <id> <ram> <disk> <vcpus>
openstack flavor create --id <id> \
--ram <size-mb> \
--disk <size-gb> \
--vcpus <num-cpu> \
<flavor_name>

#フレーバ削除
nova flavor-delete <flavor>
openstack flavor delete <flavor>


#キーペア一覧
nova keypair-list
openstack keypair list

#キーペアの作成
nova keypair-add <key_name>
openstack keypair create <key_name>


#ハイパーバイザ一覧（コンピュートノードの一覧表示としても使える）
nova hypervisor-list
openstack hypervisor list


#ブロックストレージをインスタンスにアタッチする
nova volume-attach <server> <volume>
openstack server add volume <server> <volume>

#ブロックストレージをインスタンスからデタッチする
nova volume-detach <server> <volume>
openstack server remove volume <server> <volume>


#サーバのコンソールログ表示
nova console-log <server>
openstack console log show <server>

#インスタンスへコンソール接続するためのURLを取得（noVNC）
nova get-vnc-console <server> novnc
openstack console url show --novnc <server> 

#インスタンスへコンソール接続するためのURLを取得（xvpVNC）
nova get-vnc-console <server> xvpvnc
openstack console url show --xvpvnc <server> 

#ユーザのクォータ情報確認
nova quota-show --user <user>
openstack quota show <user>

#プロジェクトのクォータ変更
nova quota-update --cores <cores> \
--ram <ram-mb> \
<tenant>
openstack quota set --cores <cores> \
--ram <ram-mb>
<project>


#イメージ一覧（novaコマンドでもイメージ一覧表示可）
nova image-list


#セキュリティグループ一覧（novaコマンドでもセキュリティグループ操作可）
nova secgroup-list

#インスタンスに関連付けられたセキュリティグループ一覧
nova list-secgroup <server>

#セキュリティグループ作成
nova secgroup-create <name> <description>

#セキュリティグループ削除
nova secgroup-delete <sg>

#インスタンスにセキュリティグループを関連付け
nova add-secgroup <server> <sg>

#インスタンスからセキュリティグループを外す
nova remove-secgroup <server> <sg>

#セキュリティグループルール一覧
nova secgroup-list-rules <sg>

#セキュリティグループにルール作成
nova secgroup-add-rule <sg> <protocol> <from_port> <to_port> <cidr>

#セキュリティグループからルール削除
nova secgroup-delete-rule <sg> <protocol> <from_port> <to_port> <cidr>

Cinder

インスタンスに永続的なブロックストレージ機能を提供するコンポーネント。インスタンスにボリュームをまるで外付けストレージのようにつけられる。
LVM、NFS、iSCSIなど様々なバックエンドをストレージボリュームとして利用できる。デフォルトはLVM。
NFSを使用した場合はマウントポイントは"/var/lib/nova/mnt"となる。
スナップショットをボリュームに保存してテンプレートイメージとして利用することも可能。
Novaとプロセスの概念が少し似ている。(CinderはもともとNovaのプロジェクトだったが独立した)

プロセス

cinder-api

CinderのREST-APIを提供するプロセス。

cinder-scheduler

ブロックボリュームを作成するストレージ装置の選択を行うプロセス。
nova-schedulerと同様にフィルターと重み計算により装置を選択する。例えば、AvailabilityZoneによる絞り込みを行った後に空き容量が大きいものを選択する。

cinder-volume

実際にストレージ装置の制御を行うプロセス。
cinder-volumeが停止しても使用中のブロックストレージが使えなくなることはない。

cinder-backup

ブロックストレージのバックアップを行うプロセス。
バックアップにSwiftを使うことができる。

重要ファイル

/etc/cinder/cinder.conf
/etc/cinder/policy.json
/var/log/cinder配下

重要コマンド

#ボリューム一覧
cinder list
openstack volume list

#ボリューム詳細
cinder show <volume>
openstack volume show <volume>

##ボリューム作成
cinder create --name <name> <size>
openstack volume create --size <size> <name>

##ボリューム削除
cinder delete <volume>
openstack volume delete <volume>


#スナップショット一覧
cinder snapshot-list
openstack snapshot list

#スナップショット詳細
cinder snapshot-show <snapshot>
openstack snapshot show <snapshot>

#スナップショット作成
cinder snapshot-create --name <name> <volume>
openstack snapshot create --name <name> <volume>

#スナップショット削除
cinder snapshot-delete <snapshot>
openstack snapshot delete <snapshot>


#バックアップ一覧
cinder backup-list
openstack backup list

#バックアップ詳細
cinder backup-show <backup>
openstack backup show <backup>

#バックアップ作成
cinder backup-create --name <name> <volume>
openstack backup create --name <name> <volume>

#バックアップ削除
cinder backup-delete <backup>
openstack backup delete <backup>

#バックアップから復元
cinder backup-restore <backup>
openstack backup restore <backup>

Swift

オブジェクトストレージ機能を提供するコンポーネント。
Swiftでは"アカウント情報"と"コンテナ（ディレクトリ）情報"と"オブジェクト（ファイル）"の3種類のファイルを管理する。これらへのアクセスはSwiftのプロキシサーバーを経由する必要があり、プロキシサーバーでは認証や負荷分散が行われる。
コンテナにオブジェクトをアップロードするとコンテナとオブジェクトは自動でレプリカが作成され、各ストレージノードに冗長保管される。冗長保管のため耐障害性が高い。デフォルトでは3つのゾーンに冗長化される。
プロセス間はAMQPでなくREST-APIでやり取りを行うため、HTTPプロトコルでファイルのやりとりを行う。
実運用環境においては最低でも5台のストレージノードを利用するのが推奨されている。
大きなサイズのファイルや静的なファイルの保管に向いている。
ブロックストレージのバックアップの保存先としても利用される。
AWSのS3相当。

プロセス

swift-proxy-server

SwiftのREST-APIを提供するプロセス。

swift-account-server

アカウント管理のREST-APIを提供し、実際に操作するプロセス。

swift-container-server

コンテナ情報管理のREST-APIを提供し、実際に操作するプロセス。

swift-object-server

オブジェクト管理のREST-APIを提供し、実際に操作するプロセス。

ビルダーファイル

リングファイル生成用の中間ファイル。
"レプリカ数"、"パーティション数"、"ディスク情報"が定義されたファイル。
"レプリカ数"では複製する数を指定する。
"パーティション数"では分散配置する物理ディスクをどれだけ細かく分割するかを指定する。多いほど同じ場所に配置されにくくなるが、メモリを大きく消費してしまう。
"ディスク情報"ではディスクのサーバのIPアドレス、デバイス名、ゾーン情報を指定する。ゾーンとは例えば「サーバ」、「電源」、「ラック」、「ネットワーク装置」、「データセンター」などである。同じゾーンのディスクには複製されない。ゾーン毎に重みを指定することで優先的に使用したいゾーンを指定することができる。

リングファイル

ファイルとファイルの格納場所（ハッシュ化されたパス名）のマッピングを管理するファイル。
デバイス名、swiftノードのIPアドレス、ポート番号、パーティション番号（実際にはハッシュ値から計算するための整数値）、レプリカ数などが含まれる。
アカウント、コンテナ、オブジェクトそれぞれに用意する。
同一のリングファイルを各ストレージサーバに配置する。これにより同一のルールにしたがって冗長保管が行われる。
ストレージサーバの追加や削除がある場合はビルダーファイルを編集して、リバランスして、再度リングファイルを生成し直す必要がある。

重要コマンド

#コンテナの一覧
swift list
openstack container list

#コンテナの詳細
swift stat <container>
openstack container show <container>

#コンテナの作成
swift post <container_name>
openstack container create <container_name>

#コンテナの削除
swift delete <container>
openstack container delete <container>


#オブジェクト一覧
swift list <container>
openstack object list <container>

#オブジェクト詳細
swift stat <contaier> <object>
openstack object show <container> <object>

#オブジェクトをコンテナにアップロード
swift upload <container> <object>
openstack object create <container> <object>

#カレントディレクトリにオブジェクトをダウンロード
swift download <container> <object>
openstack object save <container> <object>

#オブジェクトの削除
swift delete <container> <object>
openstack object delete <container> <object>

#ビルダーファイルの詳細
swift-ring-builder <builder_file>

#ビルダーファイルを新規作成
swift-ring-builder <builder_file_name> create <partition> <replica> <disk>

#ビルダーファイルに情報付加
##zone、ip、port、deviceでストレージノード情報の追加
##weightで追加ストレージノードの重みを指定する
swift-ring-builder <builder_file> add --zone <zone> \
--ip <ip> \
--port <port> \
--device <device> \
--weight <weight>

#リングファイルのリバランス（追加内容の反映）
swift-ring-builder <builder_file> rebalance

重要ファイル

/etc/swift/swift.conf
/etc/swift/proxy-server.conf
/etc/swift/account-server.conf
/etc/swift/container-server.conf
/etc/swift/object-server.conf
/var/log/swift配下

その他重要コンポーネント

コアコンポーネントではないが重要なコンポーネントをまとめる。

Horizon

Web-UIを提供するコンポーネント。

重要ファイル

/etc/openstack-dashboard/local_settings.py

Ironic

物理マシンを仮想インスタンスのように管理する機能を提供するコンポーネント。
PXE、DHCP、FTP(HTTP)、IPMIなどの既存技術を利用。
仮想インスタンスを扱うときとの違いはnova-computeが扱うドライバがlibvirtでなくベアメタルであるだけ。
仮想ネットワークタイプはflatを利用する。

プロセス

ironic-conductor

IPMI経由でのベアメタルノードの電源投入やiSCSI経由でのベアメタルノードへのイメージ転送を行うプロセス。

ironic-python-agent

ブートローダのインストールやOSイメージのインストール等を行うためのREST-APIを提供するプロセス。

ベアメタルプロビジョニングの流れ

1. IPMIで遠隔電源オン
2. PXEブート開始
3. PXEサーバ（FTPやHTTPなど)からOS読み込み
4. OSをディスクに書き込み
5. PXEブートからディスクブートに切り替え
6. OS起動

重要コマンド

#ベアメタルノード一覧
ironic node-list

#ベアメタルノード詳細
ironic node-show <node>

#ベアメタルノード追加
ironic node-create  -d <driver> -n <node_name>

#ベアメタルノード削除
ironic node-delete <node>

Heat

テンプレートベースのオーケストレーション機能を提供するコンポーネント。
スタックと呼ばれる複数のインスタンスグループを管理する。
まとめて複数インスタンスを生成、コンフィグ設定、ミドルウェアのインストール、アプリケーションのビルドなどをコマンド1つで自動化できる。
AWS CloundFormation相当。

テンプレート

yaml形式。
テンプレートのバージョン、テンプレートの概要説明、スタック生成時に与えるパラメータ（フレーバー、鍵の指定など）、スタックを構成するリソース（どのイメージ使うか、どのサブネット使うかなど）などに関する記述をする。

重要ファイル

/etc/heat/heat.conf
/var/log/heat/heat-engine.log

重要コマンド

#スタックの一覧
heat stack-list

#スタック詳細
heat stack-show <stack>

#スタック作成
##-fでテンプレートファイルを指定する
##-Pでテンプレートファイルに与えるキーバリューを指定する
heat stack-create -f <template_file> \
-P <KEY1=VALUE1;KEY2=VALUE2...> \
<stack_name>

#スタック削除
heat stack-delete <stack>

#スタックの更新
heat stack-update -f <template_file> \
-P <KEY1=VALUE1;KEY2=VALUE2...> \
<stack_name>

Ceilometer

リソース使用状況の記録とモニタリング機能を提供するコンポーネント。
Horizonと組み合わせることで統計情報などを可視化できる。

プロセス

ceilometer-agent-central

コントローラーノード上で実行され、OpenStackサービスのリソース使用状況をポーリングするプロセス。

ceilometer-agent-compute

コンピュートノード上で実行され、インスタンスの使用状況をポーリングするプロセス。

ceilometer-agent-notification

OpenStackサービスから通知されるメッセージを収集するプロセス。

ceilometer-agent-ipmi

各ノードのIPMI情報をポーリングするプロセス。

重要ファイル

/etc/ceilometer/cilometer.conf
/var/log/ceilometer/配下

重要コマンド

#測定項目の一覧
ceilometer meter-list

#サンプリング値
ceilometer sample-list -m <item>

Trove

DBaaS機能を提供するコンポーネント。
trove-agentを起動イメージに追加しておくことでインスタンス起動と同時にデータベースのインストールおよびセットアップが行われる。

Sahara

Hadoopクラスタのデプロイと管理の簡易化を提供するコンポーネント。
AWSのElasticMapReduce(EMR)相当。
Hadoopが処理するデータの保管場所としてSwiftが利用できる。
(※OPCEL対策　Sa"ha"raのhaが"ha"doopのhaで憶える)

Zaqar

マルチテナントに対応したメッセージキューサービスを提供するコンポーネント。
AWSのSQS相当。
(※OPCEL対策　Za"q"arのqがmessage"q"のqで憶える)

Murano

アプリケーションカタログ機能を提供するコンポーネント。
Horizonと連携することでDashboard上のボタンを押すだけでアプリケーションのデプロイを行える。
(※OPCEL対策　Mur"a"noのaが"a"pplication catalogのaで憶える)

Magnum

Container-as-a-Serviceを提供するコンポーネント。
コンテナを仮想インスタンス(nova)や物理マシン(Ironic)と同じ感覚で扱える。

Barbican

パスワード、暗号鍵、X.509証明書の管理機能を提供するコンポーネント。

Manila

インスタンス間の共有ファイルサービスを提供するコンポーネント。

Designate

DNSサービスを提供するコンポーネント。

トラブルシューティング

OpenStackの環境構築やサービス利用でうまくいかない場合は以下の方法でヒントを探してみてください。

• 該当してそうなコンポーネントの/var/log/配下のERRORログを確認する。
• openstackコマンドのデバッグオプションを利用してどこのタイミングで失敗しているかを確認する。
• コンポーネントの設定ファイルのDEFAULTセクションに"debug=true"と記述してコンポーネントを再起動する。（通常モードでは見られなかったヒントになるログを確認できる場合がある。）

その他

クォータ

ユーザが利用できる最大リソースの制限。
Novaのクォータではメモリ、仮想コア数、セキュリティグループ数、キーペア数の制限ができる。
Cinderのクォータではスナップショットの数を制限できる。
クォータを定義しない場合はデフォルトの設定が適用される。

参考

旧コマンド一覧
https://docs.openstack.org/mitaka/cli-reference/common/conventions.html

新コマンド一覧
https://docs.openstack.org/python-openstackclient/pike/cli/command-list.html