Mirantis OpenStack 9.1 が2016年10月14日（JST）にリリースされました。
9.0 から 9.1 へマイナーアップデートを試してみましたので投稿致します！

結構長いブログになってしまったので、 目次 をみて読み飛ばしてください。

手順は下記のサイトを参考にしています。

今回は、アップデート手順を簡単なシステム構成でさらっと流してみるところまでのご紹介です！

Updateしたシステム構成

下記のシステム構成のEnvironmentをアップデートしました。

※アップデート対象は、 Fuel Master , Fuel Slave(2台) となります。
※FuelSlave側はサーバ再起動はされず、 プロセスの再起動はされている ようです。よって、OpenStackのAPIはサービスダウンタイムが発生します。
※MySQLやRabbitMQはクラスタ構成を組んでいません。
※この構成をアップデートするのに要した時間は事前準備も含めて、 約2～3時間程度 です。

更新手順を開始する前に

マニュアルに、「メンテナンスウィンドウを計画し、テスト、ステージング環境の最新情報をバックアップする必要がある」と注意書きがあり、以下の5つの項目をチェックする必要があるそうです。

• メンテナンス計画を立てること。
• バックアップを行うこと。
• Fuel Masterがインターネットへ接続できていること。
• /var/www/nailgunディレクトリの空きが2.5GB以上あること。
• ラボやテスト環境で検証してから実施すること。

今回はせっかくなので、

• バックアップ
• ディスク空き容量の確認
• Internetへ接続確認

の3つを確認していきたいと思います。

事前準備：バックアップ

手順は下記を参考にします。
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/upgrade/backup-fuel.html

• octaneのインストール
  
  途中でインストールを続けてよいか？と聞かれるので、yを押す。
  
  2回聞かれるのでyを入力してEnterを押下する。
  
  下記のように、Complete!と表示されればfuel-octaneのインストール完了。
  

• バックアップ
  コンフィグバックアップ
  
  バイナリーとパッケージバックアップ
  
  コンフィグバックアップは3MB程度で、バイナリ＆パッケージバックアップは2.7GBでした。
  
  このファイルUSBなどにコピーして保管しておいてください。

事前準備：ディスク空き容量の確認

空きディスクが現在4.7GBでした。
2.5GB以上の空きディスクが要求されていますが、まぁぎりあるのでこのまま進んでみます。

事前準備：Internetへの接続確認

通っていますね。
この確認をFuelSlaveの全Nodeでも確認しておいてください。
cudetというコマンドを後ほど実行しますが、その際に、apt-get updateでリポジトリに接続できるか確認しているようです。

アップグレード

事前作業が済みましたので、 Mirantis OpenStack 9.0 環境から Mirantis OpenStack 9.1 の環境へアップデートしていきます。

Update手順１：Fuel MasterにSSHでログイン

ログインしましょう。（説明省略）

Update手順２：バージョン確認

MOSアップデート用のリポジトリリストが利用可能であることを確認します。

cat /etc/yum.repos.d/mos-updates.repo

上記のように表示されれば問題ないようです。
カスタマイズしている場合は別途書き換えが必要です。（マニュアル参照してください）

Update手順３：yumキャッシュクリア

yumのキャッシュをクリアします。

yum clean all

Update手順４：整合性チェックツールCudetインストール

整合性チェックツール Cudet をインストールします。
このツールは、fuel2 のために必要な更新コマンドが含まれています。
cudetコマンドが打てるようになり、これによって、FuelSlaveノードのソースやコンフィグファイルをカスタマイズしている場合に変更点が検出できるようになります。

yum install python-cudet

yを入力します。

下記のように、Complete! と表示されれば Cudet のインストール完了。

Update手順５：整合性チェック

Cudet を使用して、環境の整合性チェック（ソースやコンフィグをカスタマイズしている個所の洗い出し・検出）を実行します。
引数の cudet-id は、fuel env コマンドで確認します。
ENV_ID に紐づかれたFuelSlaveノードを対象にチェックされます。

cudet -e <ENV_ID>

Environmentは、Controllerを1台とComputeを1台、デプロイ済みのものを用意していたので、これを指定します。
※注意：このコマンド時に、Fuel Slave（Fuelに接続されているNode達）へ接続かけて状態をチェックしているようなので、Nodeの電源が落ちているとWarningなどが出ます。
「Collecting data from 2 nodes:」と表示されたあと応答までしばらく時間がかかります。
2台でだいたい5分程度 でした。

3台分の結果が表示されています。
「Versions verification analysis: OK」と出ているので、手順を続けてみます。

ここで変更点・差分が表示された場合、自らその変更点を確認して問題ないか確認しておきます。
たとえば、ソースコードに自分でパッチを当てていた場合、OpenStackのGAバージョンと差分がでるので、
そのパッチは、上書きされて消される可能性があるので、アップデート後、自分でそのパッチを充てなおす必要があります。
ご注意ください。

Update手順６：Fuel Masterの事前準備

Fuel Master 上に 新nailgun や不足のパッケージをインストールします。
また、Nailgun DBsyncが実行され、nailgunサービスを再起動されます。

update-prepare prepare master

「Complete!」と表示されているので問題なく最新化されたようです。

Update手順７：Fuel SlaveのEnvironmentの事前準備

Environmentの準備をします。
これは、Environmentに属されているFuelSlave（各ノード）でapt-get updateを行っているようです。
このコマンドを実行すると各Nodeがupdateできるか事前にチェックしているようです。

[root@fuel ~]# update-prepare prepare env 1
Warning: Permanently added '192.168.114.103' (ECDSA) to the list of known hosts.
W: GPG error: http://mirror.fuel-infra.org mos9.0-holdback Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BCE5CC461FA22B08
W: GPG error: http://mirror.fuel-infra.org mos9.0-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BCE5CC461FA22B08
W: GPG error: http://mirror.fuel-infra.org mos9.0-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BCE5CC461FA22B08

GPGのKey認証エラーが出ているようです。
この場合、鍵が各ノードに配備されていないために出るログのようなので、
下記の手順をFuel Slaveとなる各ノードで実行して、この問題を回避しました。
（下記の手順はMirantisの手順にないものです）

root@node-1:~# gpg --recv-keys BCE5CC461FA22B08
gpg: requesting key 1FA22B08 from hkp server keys.gnupg.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 1FA22B08: public key "fuel-infra (Example key) <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
root@node-1:~# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/C0B21F32 2012-05-11
uid                  Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/EFE21092 2012-05-11
uid                  Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

root@node-1:~# gpg -a --export BCE5CC461FA22B08 | apt-key add -
OK
root@node-1:~# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/C0B21F32 2012-05-11
uid                  Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/EFE21092 2012-05-11
uid                  Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

pub   2048R/1FA22B08 2015-07-21
uid                  fuel-infra (Example key) <[email protected]>
sub   2048R/6273AA09 2015-07-21

root@node-1:~#


以下、2台目にも実行しておきます。


root@node-2:~# gpg --recv-keys BCE5CC461FA22B08
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: no keyserver known (use option --keyserver)
gpg: keyserver receive failed: bad URI
root@node-2:~# gpg --recv-keys BCE5CC461FA22B08
gpg: requesting key 1FA22B08 from hkp server keys.gnupg.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 1FA22B08: public key "fuel-infra (Example key) <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
root@node-2:~# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/C0B21F32 2012-05-11
uid                  Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/EFE21092 2012-05-11
uid                  Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

root@node-2:~# gpg -a --export BCE5CC461FA22B08 | apt-key add -
OK
root@node-2:~# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/C0B21F32 2012-05-11
uid                  Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/EFE21092 2012-05-11
uid                  Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

pub   2048R/1FA22B08 2015-07-21
uid                  fuel-infra (Example key) <[email protected]>
sub   2048R/6273AA09 2015-07-21

root@node-2:~#

再び、下記のコマンドでパッケージ準備が更新されるかを確認します。

アップデートできる準備が整っているようです。
（このGPG error の件は別途Fuelコミュニティへバグレポートを書いて、パッチを出そうかと思います。）
（同様にこの問題にひっかかった方がいた場合、コメントくださるとありがたいです。）

Update手順８：事前確認

下記のコマンドでUpdateを行う前に、事前に構成のチェックを行います。

fuel2 env redeploy --noop <ENV_ID>
fuel2 task show <ENV_ID>

タスク23が進行中のようです。
statusが「ready」になるまで繰り返しコマンド「fuel2 task show 」を実行して確認します。

「ready」になりました。（10分くらい繰り返していました）
「Dry_Run_Deployment is done. No changes.」と書かれているので、
ドライラン（試し走行）を実行して問題なかったようです。

Update手順９：タスクの概要確認

次に、手順8で実行したNoopランの結果はFuelSlaveの各Nodeの /var/lib/puppet/reports//.yaml
ディレクトリに格納されるそうです。
何に使われるかわかりませんが、とりあえず、コマンドを実行して結果を出力しておきます。
（すみません、わかり次第、投稿に追記します・・・。）

注意！：
すべての環境のカスタマイズは、アップデート処理中に失われ、
アップデートを開始する価値があるかどうかの判断をするためにNOOPランとCudetによって行われたカスタマイズ検出レポートを使用するそうです。

fuel2 task history show <TASK_ID> --include-summary

Update手順１０：FuelMasterのアップデート

事前確認で問題なかったのでアップデートを開始します。

注意！：
更新中にFuelMaster上のプロセスが自動で再起動されるそうです。

update-prepare update master

実行ログが大量すぎたので画面キャプチャは取りませんでした。

「Master node update is 」と出ているので、成功したようです。
FuelMasterのアップデートにかかった時間は35分程 でした。

Update手順１１：FuelSlaveのアップデート

FuelSlaveのアップデートを行います。
FuelSlaveは2台のノード（Controller1台とCompute1台）なので、アップデートに時間がどれくらいかかるのかも確認してみたいと思います。

fuel2 update --env <ENV_ID> install

MySQLとRabbitMQを再起動させるオプション をつけることが可能で、
MySQLとRabbitMQを更新しない場合は、再起動されないようです。
もし、再起動させたくない場合はオプションをつけなければよさそうです。
（まだオプション無しは試していませんがマニュアルにはオプションを付けた場合の説明だけがあります。）

今回のアップデート構成はController1台なので、MySQLやRabbitMQはクラスタ構成をとっていない構成となっています。

--restart-rabbit 
--restart-mysql

せっかくなので、オプションをつけて実行をしてみます！

fuel2 update --env <ENV_ID> install --restart-rabbit --restart-mysql

再起動されるのか、ControllerNodeにログインして、
「watch 'ps -ef | grep mysqld | grep -v grep'」コマンドと
「watch 'ps -ef | grep rabbitmq-server | grep -v grep | grep -v monitor'」コマンドで
起動時刻をウォッチしたいと思います。

Oct18に起動おり、アップデートを実行した日付はOct19なので再起動された場合、ここが変わるはず。

このアップデートは非同期で各OpenStackNode（FuelSlave）にアップデートされるので、下記のコマンドで状況を確認することができようです。

fuel2 task show <TASK_ID>

このコマンドを繰り返して実行し、「progress」を見ると徐々に進捗が進んでいることがみてとれます。

Oct19ではなく、現在の時刻に表示が切り替わりました。（6:46と6:47）
FuelSlaveのアップデートを実行してから10分程度でプロセスが再起動されました。
つまり、MySQLとRabbitMQに変更が加わっていたため再起動されたということですね。
完全にアップデートを反映させるためには、オプションをつけて実行すべきかと考えます。

今回はMySQLやRabbitMQのクラスタを組んでいないので再起動の時間が数秒程度だったようですが、
クラスタを組んでいた場合はどれくらい時間がかかっていたのかわかりません。
この時間がメンテナス時間を計画する（ダウンタイム計測）ために必要なものになるでしょう。

デプロイが完了しました。
FuelSlaveのアップデートまでにかかった時間は５０分程（2Nodeぶん） でした。
なので、おそらく1台あたり25分かかる計算なのかも知れません。（次回3ノードで試せばわかるか・・・。）

Update手順１１：Mirantis OpenStack 9.1にアップデートされたか確認

下記のコマンドで確認します。

cudet -e <ENV_ID>

「Potential updates: ALL NODES UP-TO-DATE」と表示されているので正常にアップデートされました。

次回の記事では、9.1に関するアップデートの内容とその動作検証を記載したいと思います！

おたのしみに☆彡