Novaのインストールについて
670 views
Skip to first unread message
d.shen
Mar 22, 2011, 3:36:21 AM3/22/11
to openstack-ja
OpenStackユーザ会の皆様
お世話になります。
NTT ATの沈と申します。
OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch03s02.html）
に記載されているインストールプログラム（nova-CC-install-v1.1.sh）を用いて１台のPCにNovaのインストール
を試みています。
インストールプログラム動作終了後に、OpenStackのドキュメント
（http://docs.openstack.org/openstack-compute/admin/content/
ch03s03.html）に記載されている
SQL（mysql -u$MYSQL_USER -p$MYSQL_PASS nova -e 'select * from
services;'）を実行した
ところ、SQLの実行結果に「nova-network」、「nova-compute」及び「nova-scheduler」が表示されていた
ので、インストールプログラムを用いたNovaのインストール自体は成功したと思われます。
しかし、OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch05s01.html）
に記載されているクラウドアーカイブを配布するコマンド（uec-publish-tarball)の実行を試みた下記に示す
メッセージが表示されました。
ghost@ghost-desktop:~$ uec-publish-tarball $image dub-bucket x86_64
Unable to run euca-describe-images. Is euca2ools environment set up?
コマンドからの戻り値を見る限り、uec-publish-tarballより内部で起動されるeuca2oolsコマンドの環境情報
が正しくセットされていない為に、uec-publish-tarballコマンドの実行に失敗したと思いますが、OpenStackの
ドキュメントを見てもeuca2oolsコマンドの環境情報の設定方法に言及する箇所が見当たりません。
uec-publish-tarballコマンドを正しく実行させるためには、どのような環境情報をeuca2oolsコマンドにセットすれ
ばよいでしょうか？ご存知の方教えていただけませんでしょうか？
お世話になります。
NTT ATの沈と申します。
OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch03s02.html）
に記載されているインストールプログラム（nova-CC-install-v1.1.sh）を用いて１台のPCにNovaのインストール
を試みています。
インストールプログラム動作終了後に、OpenStackのドキュメント
（http://docs.openstack.org/openstack-compute/admin/content/
ch03s03.html）に記載されている
SQL（mysql -u$MYSQL_USER -p$MYSQL_PASS nova -e 'select * from
services;'）を実行した
ところ、SQLの実行結果に「nova-network」、「nova-compute」及び「nova-scheduler」が表示されていた
ので、インストールプログラムを用いたNovaのインストール自体は成功したと思われます。
しかし、OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch05s01.html）
に記載されているクラウドアーカイブを配布するコマンド（uec-publish-tarball)の実行を試みた下記に示す
メッセージが表示されました。
ghost@ghost-desktop:~$ uec-publish-tarball $image dub-bucket x86_64
Unable to run euca-describe-images. Is euca2ools environment set up?
コマンドからの戻り値を見る限り、uec-publish-tarballより内部で起動されるeuca2oolsコマンドの環境情報
が正しくセットされていない為に、uec-publish-tarballコマンドの実行に失敗したと思いますが、OpenStackの
ドキュメントを見てもeuca2oolsコマンドの環境情報の設定方法に言及する箇所が見当たりません。
uec-publish-tarballコマンドを正しく実行させるためには、どのような環境情報をeuca2oolsコマンドにセットすれ
ばよいでしょうか？ご存知の方教えていただけませんでしょうか？
d.shen
Mar 22, 2011, 4:51:40 AM3/22/11
to openstack-ja
OpenStackユーザ会の皆様
お世話になります。
NTT ATの沈と申します。
利用している環境情報の記述を忘れてしまった為に、若干
追記させていただきたいと思います。
OS：Ubuntu 10.04 Desktop (64Bit版）
Novaに関しては、インストールプログラム（nova-CC-install-v1.1.sh）内で
直接apt-getでインストールされました。 dpkg -l コマンドでNovaのバージョン
を確認した所「2011.1~bzr645-0ubuntu0ppa1~lucid1」となっていました。
https://launchpad.net/nova/には、「Latest version is 2011.1.1 」と記載されて
いるので、インストールプログラム（nova-CC-install-v1.1.sh）で直接最新版
のNovaを取得していると思われます。
ghost@ghost-desktop:~$ dpkg -l | grep nova
ii nova-api
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - API frontend
ii nova-common
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - common files
ii nova-compute
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - compute node
ii nova-network
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Network thingamaj
ii nova-objectstore
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - object store
ii nova-scheduler
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Scheduler
ii python-nova
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Python libraries
以上簡単ではありますが、利用環境を記述させていただきました。Novaのインストール
作業に関してヒント等を頂けませんでしょうか。
お世話になります。
NTT ATの沈と申します。
利用している環境情報の記述を忘れてしまった為に、若干
追記させていただきたいと思います。
OS：Ubuntu 10.04 Desktop (64Bit版）
Novaに関しては、インストールプログラム（nova-CC-install-v1.1.sh）内で
直接apt-getでインストールされました。 dpkg -l コマンドでNovaのバージョン
を確認した所「2011.1~bzr645-0ubuntu0ppa1~lucid1」となっていました。
https://launchpad.net/nova/には、「Latest version is 2011.1.1 」と記載されて
いるので、インストールプログラム（nova-CC-install-v1.1.sh）で直接最新版
のNovaを取得していると思われます。
ghost@ghost-desktop:~$ dpkg -l | grep nova
ii nova-api
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - API frontend
ii nova-common
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - common files
ii nova-compute
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - compute node
ii nova-network
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Network thingamaj
ii nova-objectstore
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - object store
ii nova-scheduler
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Scheduler
ii python-nova
2011.1~bzr645-0ubuntu0ppa1~lucid1 OpenStack Compute -
Nova - Python libraries
以上簡単ではありますが、利用環境を記述させていただきました。Novaのインストール
作業に関してヒント等を頂けませんでしょうか。
Silver Devil
Mar 22, 2011, 4:59:44 AM3/22/11
to openst...@googlegroups.com
JAISTの松井です。
数日前に動かしてみましたが
同じ箇所で躓いています。
uec-publish-tarballで登録できないのは
バグでAPIの動作をしていないようです。
（報告済みのようです）
修正済みのバージョンや、きちんと動作するバージョンはないのでしょうか？
ちなみに、こちらの手順を参考に手動で登録したらインスタンスが起動できました。
2011年3月22日16:36 d.shen <d.s...@ntt-at.co.jp>:
Masanori Itoh
Mar 22, 2011, 9:22:42 PM3/22/11
to openstack-ja
NTTデータの伊藤です。
このバグ報告
https://bugs.launchpad.net/nova/+bug/719002
のやりとりを追ってみると、
https://bugs.launchpad.net/nova/+bug/719093
のバグに対する修正にて修正されているようです。
また、
| 認した所「2011.1~bzr645-0ubuntu0ppa1~lucid1」となっていました。
ということで、第二版(Bexar)ですね。これだと、もうnova のバージョンがけっこう古くなっている
ので、既知のバグを踏みがちになるかもしれません。
今、次の第3版(Cactus Release)‘が新機能の提案は既に〆切になってQAの phase に入ってますので、
https://launchpad.net/~nova-core/+archive/trunk
にあるパッケージを使うとよいかもしれません。
目的が検証なのか、開発なのかにもよりますが、後者であれば trunk を使ったほうがよいと思います。
前者であれば、急いでいない限り、Cactusのリリースをもう少しだけ待つのがいいと思います。
とりいそぎ。
> > ばよいでしょうか？ご存知の方教えていただけませんでしょうか？- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
このバグ報告
https://bugs.launchpad.net/nova/+bug/719002
のやりとりを追ってみると、
https://bugs.launchpad.net/nova/+bug/719093
のバグに対する修正にて修正されているようです。
また、
| 認した所「2011.1~bzr645-0ubuntu0ppa1~lucid1」となっていました。
ということで、第二版(Bexar)ですね。これだと、もうnova のバージョンがけっこう古くなっている
ので、既知のバグを踏みがちになるかもしれません。
今、次の第3版(Cactus Release)‘が新機能の提案は既に〆切になってQAの phase に入ってますので、
https://launchpad.net/~nova-core/+archive/trunk
にあるパッケージを使うとよいかもしれません。
目的が検証なのか、開発なのかにもよりますが、後者であれば trunk を使ったほうがよいと思います。
前者であれば、急いでいない限り、Cactusのリリースをもう少しだけ待つのがいいと思います。
とりいそぎ。
>
> - 引用テキストを表示 -
d.shen
Mar 23, 2011, 4:28:07 AM3/23/11
to openstack-ja
OpenStack ユーザ会の皆様
お世話になっております。NTT ATの沈です。
どこにぶら下げるべきか少々悩みましたけど、後からOpenStackユーザ会に
加入した人が問題の経緯を容易に理解できるようこちらにつけました。
とりあえずその後の経過＆インストールプログラム（nova-CC-install-v1.1.sh）
の実行に失敗した箇所を発見致しましたので皆様にご報告致します。
まず最初に、JAISTの松井様、NTTデータの伊藤様アドバイス
有り難うございます。
【その後の経過内容】
松井様より提示して頂いたURL（http://wiki.openstack.org/RunningNova/
ManualImageRegistration）
の内容を確認したところ、OpenStackプロジェクトが配布しているテスト用イメージ
データをtarコマンドで展開すると、「aki-lucid」、「ami-tiny」、「ari-lucid」なるディレクトリ
が作成され、また各ディレクトリ内には「image及びinfo.jsonなるファイル」が存在するみたいですけど、
OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch05s01.html） に記載されているテスト用イメージデータ（ubuntu1010-UEC-localuser-
image.tar.gz）
を展開すると下記に示すファイルしかありませんでした。
ghost@ghost-desktop:~$ tar zxvf ./ubuntu1010-UEC-localuser-
image.tar.gz
maverick-server-uec-amd64-floppy
maverick-server-uec-amd64.img
maverick-server-uec-amd64-loader
maverick-server-uec-amd64-vmlinuz-virtual
実際に展開されたファイルと松井様よりご紹介していただいたURLに記載されている内容が
少々異なっていた為に、URLに記載されている内容を実行しませんでした。
【インストールプログラム（nova-CC-install-v1.1.sh）の実行に失敗した箇所】
インストールプログラム（nova-CC-install-v1.1.sh）を実行した際のログファイルの再確認
を実施した所、インストール時に下記に示す処理の実行に失敗したことが判明しました。
[ソースコード 533行 ～ 537行]
533 /usr/bin/python /usr/bin/nova-manage project zipfile $NOVA_PROJECT
$NOVA_PROJECT_USER /root/creds/novacreds.zip &>> $LOGFILE
534 sleep 3
535 unzip -d /root/creds /root/creds/novacreds.zip &>> $LOGFILE
536 . /root/creds/novarc
537 cat /root/creds/novarc >> ~/.bashrc
上記ソースでは、nova-manageコマンドを実行した際に生成するファイル
を「/root/creds/novacreds.zip」に保存しようとしています。その後、生成zipファイルを
「/root/creds」に解凍して、解凍した「/root/creds/novarc」ファイルを「.bashrc」
に追記します。
しかし、インストールプログラム（nova-CC-install-v1.1.sh）が出力したログファイル
（/var/log/nova/nova-install.log)には、
unzip: cannot find or open /root/creds/novacreds.zip, /root/creds/
novacreds.zip.zip or /root/creds/novacreds.zip.ZIP.
が記録されていましたので、「/root/creds/novarc」ファイルを「.bashrc」への追記が失敗した
ことになります。実際問題lsコマンドで「/root/creds」内を確認しても novarcファイルが存在し
ませんでした。
ghost@ghost-desktop:~$ sudo ls -la /root/creds
合計 8
drwxr-xr-x 2 root root 4096 2011-03-22 11:17 .
drwx------ 12 root root 4096 2011-03-22 11:17 ..
とりあえず、上記の533行 ～ 537行を再度手動による実行を試みます。
お世話になっております。NTT ATの沈です。
どこにぶら下げるべきか少々悩みましたけど、後からOpenStackユーザ会に
加入した人が問題の経緯を容易に理解できるようこちらにつけました。
とりあえずその後の経過＆インストールプログラム（nova-CC-install-v1.1.sh）
の実行に失敗した箇所を発見致しましたので皆様にご報告致します。
まず最初に、JAISTの松井様、NTTデータの伊藤様アドバイス
有り難うございます。
【その後の経過内容】
松井様より提示して頂いたURL（http://wiki.openstack.org/RunningNova/
ManualImageRegistration）
の内容を確認したところ、OpenStackプロジェクトが配布しているテスト用イメージ
データをtarコマンドで展開すると、「aki-lucid」、「ami-tiny」、「ari-lucid」なるディレクトリ
が作成され、また各ディレクトリ内には「image及びinfo.jsonなるファイル」が存在するみたいですけど、
OpenStackのドキュメント（http://docs.openstack.org/openstack-compute/admin/
content/ch05s01.html） に記載されているテスト用イメージデータ（ubuntu1010-UEC-localuser-
image.tar.gz）
を展開すると下記に示すファイルしかありませんでした。
ghost@ghost-desktop:~$ tar zxvf ./ubuntu1010-UEC-localuser-
image.tar.gz
maverick-server-uec-amd64-floppy
maverick-server-uec-amd64.img
maverick-server-uec-amd64-loader
maverick-server-uec-amd64-vmlinuz-virtual
実際に展開されたファイルと松井様よりご紹介していただいたURLに記載されている内容が
少々異なっていた為に、URLに記載されている内容を実行しませんでした。
【インストールプログラム（nova-CC-install-v1.1.sh）の実行に失敗した箇所】
インストールプログラム（nova-CC-install-v1.1.sh）を実行した際のログファイルの再確認
を実施した所、インストール時に下記に示す処理の実行に失敗したことが判明しました。
[ソースコード 533行 ～ 537行]
533 /usr/bin/python /usr/bin/nova-manage project zipfile $NOVA_PROJECT
$NOVA_PROJECT_USER /root/creds/novacreds.zip &>> $LOGFILE
534 sleep 3
535 unzip -d /root/creds /root/creds/novacreds.zip &>> $LOGFILE
536 . /root/creds/novarc
537 cat /root/creds/novarc >> ~/.bashrc
上記ソースでは、nova-manageコマンドを実行した際に生成するファイル
を「/root/creds/novacreds.zip」に保存しようとしています。その後、生成zipファイルを
「/root/creds」に解凍して、解凍した「/root/creds/novarc」ファイルを「.bashrc」
に追記します。
しかし、インストールプログラム（nova-CC-install-v1.1.sh）が出力したログファイル
（/var/log/nova/nova-install.log)には、
unzip: cannot find or open /root/creds/novacreds.zip, /root/creds/
novacreds.zip.zip or /root/creds/novacreds.zip.ZIP.
が記録されていましたので、「/root/creds/novarc」ファイルを「.bashrc」への追記が失敗した
ことになります。実際問題lsコマンドで「/root/creds」内を確認しても novarcファイルが存在し
ませんでした。
ghost@ghost-desktop:~$ sudo ls -la /root/creds
合計 8
drwxr-xr-x 2 root root 4096 2011-03-22 11:17 .
drwx------ 12 root root 4096 2011-03-22 11:17 ..
とりあえず、上記の533行 ～ 537行を再度手動による実行を試みます。
d.shen
Mar 23, 2011, 4:46:21 AM3/23/11
to openstack-ja
OpenStack ユーザ会の皆様
お世話になっております。NTT ATの沈です。
自己レスです。とりあえず、ソースコードの533行目
お世話になっております。NTT ATの沈です。
の手動実行を試みた結果下記の通りになりました。
ghost@ghost-desktop:~$ sudo /usr/bin/python /usr/bin/nova-manage
project zipfile project1 admin /root/creds/novacreds.zip
[sudo] password for ghost:
No more networks available. If this is a new installation, you need
to call something like this:
nova-manage network create 10.0.0.0/8 10 64
なにやらよく分からない結果になりました。ちなみに、上記コマンド
実行終了後に、再度lsコマンドにて「/root/creds」配下を確認した所、
novacreds.zipファイルが生成されませんでした、、、、、、、。
ghost@ghost-desktop:~$ sudo ls -la /root/creds
d.shen
Mar 24, 2011, 2:50:22 AM3/24/11
to openstack-ja
OpenStack ユーザ会の皆様
お世話になっております。NTT ATの沈です。自己レスです。インストールプログラム
（nova-CC-install-v1.1.sh）がインストール作業時に生成したログファイル
（/var/log/nova/nova-install.log)の内容を再度確認したら、
/usr/bin/python /usr/bin/nova-manage network create $PROJECT_CIDR
$NOVA_NETWORK_NUMBER $IPS_PER_NETWORK &>> $LOGFILE
の実行にも失敗していた事が判明しました。Novaネットワークの作成に失敗した為に、手動にて
ghost@ghost-desktop:~$ sudo /usr/bin/python /usr/bin/nova-manage
project zipfile project1 admin /root/creds/novacreds.zip
上記コマンドを実行した際に、コンソールに下記に示す内容のエラーメッセージが表示されるの
も納得です。
No more networks available. If this is a new installation, you need
to call something like this:
nova-manage network create 10.0.0.0/8 10 64
さて、肝心の失敗原因ですけど、/var/log/nova/nova-install.logには下記の内容が記録されて
いました。
2011-03-22 11:17:32,427 CRITICAL nova.root [-]
(nova.root): TRACE: Traceback (most recent call last):
(nova.root): TRACE: File "/usr/bin/nova-manage", line 694, in
<module>
(nova.root): TRACE: main()
(nova.root): TRACE: File "/usr/bin/nova-manage", line 686, in main
(nova.root): TRACE: fn(*argv)
(nova.root): TRACE: File "/usr/bin/nova-manage", line 500, in create
(nova.root): TRACE: vpn_start=int(vpn_start))
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/nova/network/
manager.py", line 346, in create_networks
(nova.root): TRACE: net['dhcp_start'] = str(project_net[2])
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/IPy.py", line
880, in __getitem__
(nova.root): TRACE: return IP(IPint.__getitem__(self, key))
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/IPy.py", line
561, in __getitem__
(nova.root): TRACE: raise IndexError
(nova.root): TRACE: IndexError
(nova.root): TRACE:
上記のログによれば/usr/lib/pymodules/python2.6/IPy.pyの561行目には
「raise IndexError」が記録されていますが、ログに記録されているソース
コードの番号を下から順番にトレースしたら、どうやらNovaネットワーク作成
時にNovaネットワークで利用するIPアドレスの処理に失敗しているみたいです。
とりあえず、ディスカッションボードをお騒がせしたお詫びに、現時点で当方が
判明したNovaのインストールプログラム（nova-CC-install-v1.1.sh）
にまつわる問題に関して分かっている範囲を一度まとめてみます。
【インストールプログラム（nova-CC-install-v1.1.sh）の問題点】
（１）インストールプログラムより実行された外部コマンド群の戻り値を確認し
ていません。別の言い方をすれば、外部コマンドの実行は常に成功するもの
と仮定されています。その為に、523行～525行及び53行～537行のような
のようなNovaインストールにとって重要な処理で、実行に失敗しても
インストールプログラム的には何も無かったようにスルーされます。
523 /usr/bin/python /usr/bin/nova-manage user admin
$NOVA_PROJECT_USER &>> $LOGFILE
524 /usr/bin/python /usr/bin/nova-manage project create
$NOVA_PROJECT $NOVA_PROJECT_USER &>> $LOGFILE
525 /usr/bin/python /usr/bin/nova-manage network create
$PROJECT_CIDR $NOVA_NETWORK_NUMBER $IPS_PER_NETWORK &>> $LOGFILE
533 /usr/bin/python /usr/bin/nova-manage project zipfile
$NOVA_PROJECT $NOVA_PROJECT_USER /root/creds/novacreds.zip &>>
$LOGFILE
534 sleep 3
535 unzip -d /root/creds /root/creds/novacreds.zip &>> $LOGFILE
536 . /root/creds/novarc
537 cat /root/creds/novarc >> ~/.bashrc
（2）大して重要な問題では無いですけど、インストールプログラムは英語環境しか
考慮していません。例えば日本語環境でインストールプログラムを動かした際、
画面にデフォルト設定ならENTERキーと表示されている箇所などでは、ENTER
キーを押しても先へ進めまず、再度同様の内容（デフォルトならENTERキー）が
表示される。理由は日本語環境だとifconfigを実行した際の戻り値に日本語が
入ってくるために、下記ソースだと文字列のパース処理がうまくいかなくなり、
無限ループに陥る。知っていれば大したことは無いですけど、気づかないと地味
にハマる箇所です。
147 default=`/sbin/ifconfig -a | egrep '.*inet ' | head -n 1|perl -
pe 's/.*addr:(.+).*Bcast.*/$1/g' | tr -d " "`
さて、ある程度問題箇所を絞り込めたけど、ここから先は地道にnova-manageコマンドの
ソースコードをHackするしかないかな、、、、、、、、、。
素朴な疑問ですけど、ユーザ会の皆様は、OpenStackのインストールをどのようにやって
いますか？もしかしてnova-CC-install-v1.1.shを使わずに別の方法でインストールをされ
ていますか？宜しければ教えていただけませんでしょうか？
お世話になっております。NTT ATの沈です。自己レスです。インストールプログラム
（nova-CC-install-v1.1.sh）がインストール作業時に生成したログファイル
（/var/log/nova/nova-install.log)の内容を再度確認したら、
/usr/bin/python /usr/bin/nova-manage network create $PROJECT_CIDR
$NOVA_NETWORK_NUMBER $IPS_PER_NETWORK &>> $LOGFILE
の実行にも失敗していた事が判明しました。Novaネットワークの作成に失敗した為に、手動にて
ghost@ghost-desktop:~$ sudo /usr/bin/python /usr/bin/nova-manage
project zipfile project1 admin /root/creds/novacreds.zip
も納得です。
No more networks available. If this is a new installation, you need
to call something like this:
nova-manage network create 10.0.0.0/8 10 64
いました。
2011-03-22 11:17:32,427 CRITICAL nova.root [-]
(nova.root): TRACE: Traceback (most recent call last):
(nova.root): TRACE: File "/usr/bin/nova-manage", line 694, in
<module>
(nova.root): TRACE: main()
(nova.root): TRACE: File "/usr/bin/nova-manage", line 686, in main
(nova.root): TRACE: fn(*argv)
(nova.root): TRACE: File "/usr/bin/nova-manage", line 500, in create
(nova.root): TRACE: vpn_start=int(vpn_start))
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/nova/network/
manager.py", line 346, in create_networks
(nova.root): TRACE: net['dhcp_start'] = str(project_net[2])
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/IPy.py", line
880, in __getitem__
(nova.root): TRACE: return IP(IPint.__getitem__(self, key))
(nova.root): TRACE: File "/usr/lib/pymodules/python2.6/IPy.py", line
561, in __getitem__
(nova.root): TRACE: raise IndexError
(nova.root): TRACE: IndexError
(nova.root): TRACE:
上記のログによれば/usr/lib/pymodules/python2.6/IPy.pyの561行目には
「raise IndexError」が記録されていますが、ログに記録されているソース
コードの番号を下から順番にトレースしたら、どうやらNovaネットワーク作成
時にNovaネットワークで利用するIPアドレスの処理に失敗しているみたいです。
とりあえず、ディスカッションボードをお騒がせしたお詫びに、現時点で当方が
判明したNovaのインストールプログラム（nova-CC-install-v1.1.sh）
にまつわる問題に関して分かっている範囲を一度まとめてみます。
【インストールプログラム（nova-CC-install-v1.1.sh）の問題点】
（１）インストールプログラムより実行された外部コマンド群の戻り値を確認し
ていません。別の言い方をすれば、外部コマンドの実行は常に成功するもの
と仮定されています。その為に、523行～525行及び53行～537行のような
のようなNovaインストールにとって重要な処理で、実行に失敗しても
インストールプログラム的には何も無かったようにスルーされます。
523 /usr/bin/python /usr/bin/nova-manage user admin
$NOVA_PROJECT_USER &>> $LOGFILE
524 /usr/bin/python /usr/bin/nova-manage project create
$NOVA_PROJECT $NOVA_PROJECT_USER &>> $LOGFILE
525 /usr/bin/python /usr/bin/nova-manage network create
$PROJECT_CIDR $NOVA_NETWORK_NUMBER $IPS_PER_NETWORK &>> $LOGFILE
533 /usr/bin/python /usr/bin/nova-manage project zipfile
$NOVA_PROJECT $NOVA_PROJECT_USER /root/creds/novacreds.zip &>>
$LOGFILE
534 sleep 3
535 unzip -d /root/creds /root/creds/novacreds.zip &>> $LOGFILE
536 . /root/creds/novarc
537 cat /root/creds/novarc >> ~/.bashrc
考慮していません。例えば日本語環境でインストールプログラムを動かした際、
画面にデフォルト設定ならENTERキーと表示されている箇所などでは、ENTER
キーを押しても先へ進めまず、再度同様の内容（デフォルトならENTERキー）が
表示される。理由は日本語環境だとifconfigを実行した際の戻り値に日本語が
入ってくるために、下記ソースだと文字列のパース処理がうまくいかなくなり、
無限ループに陥る。知っていれば大したことは無いですけど、気づかないと地味
にハマる箇所です。
147 default=`/sbin/ifconfig -a | egrep '.*inet ' | head -n 1|perl -
pe 's/.*addr:(.+).*Bcast.*/$1/g' | tr -d " "`
さて、ある程度問題箇所を絞り込めたけど、ここから先は地道にnova-manageコマンドの
ソースコードをHackするしかないかな、、、、、、、、、。
素朴な疑問ですけど、ユーザ会の皆様は、OpenStackのインストールをどのようにやって
いますか？もしかしてnova-CC-install-v1.1.shを使わずに別の方法でインストールをされ
ていますか？宜しければ教えていただけませんでしょうか？
d.shen
Apr 5, 2011, 10:17:36 PM4/5/11
to openstack-ja
OpenStack ユーザ会の皆様
お世話になっております。NTT ATの沈です。自己レスです。
「uec-publish-tarballで登録できない」問題に関して、簡単な
お世話になっております。NTT ATの沈です。自己レスです。
回避策を実施すれば、uec-publish-tarballコマンドを問題なく
動かす事が出来る方法を見つけましたので参考までに報告
致します。
【コマンド実行失敗の原因】
コマンド実行に失敗する原因は、単純にuec-publish-tarball
は、コマンドを実行時に特定の環境変数が事前にシェル内
に登録されている事を前提としている作りになっています。
インストールプログラム（nova-CC-install-v1.1.sh）に従って
作業を実施しますと、uec-publish-tarballコマンドを
動かすための環境変数情報は、「/root/creds/」ディレクトリ
配下にある「novarc」というファイル及び、インストールプログラム
（nova-CC-install-v1.1.sh）を実行したユーザのホーム
ディレクトリ内の「 .bashrc 」という隠しファイルに書き込まれます。
参考までに書き込まれる環境変数情報を下記に示します。
NOVA_KEY_DIR=$(pushd $(dirname $BASH_SOURCE)>/dev/null; pwd; popd>/dev/
null)
export EC2_ACCESS_KEY="e52977be-87f7-404b-87dc-1eeafbbc1687:project1"
export EC2_SECRET_KEY="99591da9-304d-44ee-a86a-634f7674c6b4"
export EC2_URL="http://192.168.100.11:8773/services/Cloud"
export S3_URL="http://192.168.100.11:3333"
export EC2_USER_ID=42 # nova does not use user id, but bundling
requires it
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to
require this set
alias ec2-bundle-image="ec2-bundle-image --cert ${EC2_CERT} --
privatekey ${EC2_PRIVATE_KEY} --user 42 --ec2cert ${NOVA_CERT}"
alias ec2-upload-bundle="ec2-upload-bundle -a ${EC2_ACCESS_KEY} -s $
{EC2_SECRET_KEY} --url ${S3_URL} --ec2cert ${NOVA_CERT}"
export CLOUD_SERVERS_API_KEY="e52977be-87f7-404b-87dc-1eeafbbc1687"
export CLOUD_SERVERS_USERNAME="admin"
export CLOUD_SERVERS_URL="http://192.168.100.11:8774/v1.0/"
ここで注目すべき箇所は「NOVA_KEY_DIR」行に示されている
処理です。実はuec-publish-tarballコマンドを実行する際に、
「EC2_PRIVATE_KEY」、「EC2_CERT」、「NOVA_CERT」
変数に記載されているファイル（pk.pem、cert.pem、acert.pem）
を要求します。
問題はこれらのファイルは、インストールプログラム
（nova-CC-install-v1.1.sh）によって、インストール時に
「/root/creds/」ディレクトリ配下に保存されます。つまり、
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
の処理を展開すると、正しく処理が行われた場合には、
export EC2_PRIVATE_KEY=/root/creds/pk.pem
がシェルの環境変数として読み込まれます。
ところが、「NOVA_KEY_DIR」行は、実行しているユーザ
によって戻り値が変わります。どういうことかと言うと、
例えば rootユーザで動かした場合、「NOVA_KEY_DIR」行の
処理の戻り値としては「/root/creds」となるけど、違うユーザ
で動かした場合には、戻り値は「/root/creds」とはなりません。
また、仮にroot以外の違うユーザで実行した場合の戻り値が
「/root/creds」となったとしても、「/root/creds」ディレクトリ配下
のファイル（pk.pem、cert.pem、acert.pem）の読み取りは
rootユーザしか許可されていません。
読み取り権限が無いために、結果としてuec-publish-tarball
コマンドを実行する際に、要求されるファイル（pk.pem、
cert.pem、acert.pem）を読み込むことができずにコマンド
実行に失敗します。
【回避策の実行方法】
回避策に関しては色々考えられますが、ファイルのパーミッション
を変更せずにuec-publish-tarballコマンドを動かすのなら下記に
示すコマンド群を実行すれば問題を回避出来ます。
ghost@nova-2:~$ sudo su
[sudo] password for ghost:
root@nova-2:/home/ghost# source /root/creds/novarc
root@nova-2:/home/ghost#
「sudo su」コマンドでrootユーザに切り替えた後に、bashの
内部コマンドであるsourceを実行して、/root/creds/novarc
ファイルに記載された環境変数をシェルに読み込ませます。
環境変数が正しく読み込まれた場合には、uec-publish-tarball
コマンドを実行することが出来ます。
環境変数が正しくセットされたか否かを確認するには、単純に
root@nova-2:/home/ghost# echo $EC2_PRIVATE_KEY
を実行すればよいです。実行結果として画面に、/root/creds/pk.pem
と表示されていたら問題ありません。uec-publish-tarballコマンドの
実行に成功すれば、後はeuca-run-instancesコマンドを実行すれば、
登録済みのイメージデータからインスタンスを起動させることができます。
ただ、、、、、、、、、、、インスタンスの起動に成功しとしても、何故か
起動中のインスタンスに対して、pingやsshの実行が出来ません
、、、、、、、、、、orz
本家の同様の質問が上がっており、その回答内容もチェックしたけど、
うまく動作してくれません、、、、、、、、、、、 orz
起動中のインスタンスに対して、pingやsshの実施に成功した方いますか？
いたらやり方等を教えていただけませんでしょうか？
d.shen
Apr 11, 2011, 4:03:38 AM4/11/11
to openstack-ja
OpenStack ユーザ会の皆様
お世話になっております。NTT ATの沈です。自己レスです。
起動中のインスタンスに対して、pingやsshの実行が出来ない
お世話になっております。NTT ATの沈です。自己レスです。
問題に対して、色々調べてみた結果解決策が見つかったので
参考までに報告致します。
euca-get-console-output コマンドでインスタンスの出力
メッセージが拾えることを知り、試しにメッセージを拾って見たら
下記に示すエラーが出力されていました。
【エラーの内容】
2011-04-08 07:44:54,816 - DataSourceEc2.py[WARNING]: waiting for
metadata service at http://169.254.169.254/2009-04-04/meta-data/instance-id
2011-04-08 07:44:54,817 - DataSourceEc2.py[WARNING]: 07:44:54
[ 1/100]: url error [[Errno 111] Connection refused]
2011-04-08 07:44:55,820 - DataSourceEc2.py[WARNING]: 07:44:55
[ 2/100]: url error [[Errno 111] Connection refused]
本家のFAQを見たら、OpenStackコミュニティーが配布しているテス
ト用イメージデータを利用する際に、事前に下記に示すコマンドを用
いて、仮想イメージデータのルーティング設定を施す必要があるとの
記述を見つけました。（XXX.XXX.XXX.XXXにはNovaがインストール
されているサーバのIPアドレスを入力）
iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --
dport 80 -j DNAT --to-destination XXX.XXX.XXX.XXX:8773
また、状況によってはdnsmasqプロセスが通信を邪魔している場合
があるので、動いていたら事前にkillしてnova-networkの再起動を
してくださいとの記述がありました。つまり、下記のコマンドも一緒に
動かす必要がありました。
killall dnsmasq
restart nova-network
ただ、本家のFAQには上記の内容しか書かれていないけど、実際に
試すと上記の手順では上手く行かない場合があることが判明しました。
特にインスタンスが起動中の場合には、事前にインスタンスを落として
からnova-networkやnova-computeを再起動しないと上手く認識して
くれない場合があるみたいです。
話を整理すると、pingやsshが実行できない問題を解決するために、
状況によっては下記に示すコマンド群を実行する必要があります。
euca-describe-instances
euca-terminate-instances
iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --
dport 80 -j DNAT --to-destination XXX.XXX.XXX.XXX:8773
killall dnsmasq
restart nova-compute
restart nova-network
ちなみに、本家のFAQにはNovaのネットワークモデルが「FlatManager」
だと上記の問題に遭遇するから「FlatDHCPManager」或いは「VlanManager」
に変更してくださいみたいな記述があるけど、試した結果「FlatManager」のまま
でも問題無く動きました。
それにしても、Nova（Bexar）のインストールを開始してから、インスタンスが
マトモに動き出すまでエラい時間がかかってしまった、、、、、。orz
Yasuhiro Arai
Apr 11, 2011, 9:02:14 AM4/11/11
to d.shen, openst...@googlegroups.com
沈さん
こんばんは。CUPA荒井です。
> それにしても、Nova（Bexar）のインストールを開始してから、インスタンスが
> マトモに動き出すまでエラい時間がかかってしまった、、、、、。orz
人柱・・、もとい、検証と貴重な情報ありがとうございます！
euca-get-console-outputは、metadataのinstance-idを
見に行くんですね。勉強になりました。
今後も是非またレポートお待ちしております！
2011年4月11日17:03 d.shen <d.s...@ntt-at.co.jp>:
Reply all
Reply to author
Forward
0 new messages