ランドスケープのOpenstackデプロイメントがConfigure Availability Zonesで失敗する
現在のランドスケープの「OpenStack Beta」オプションを使用して、私のMAASセットアップにOpenStackをデプロイします。「アベイラビリティーゾーンの構成」で1回失敗すると、98％完了します。私の設定はKVM、Open vSwitchを利用し、現在はオブジェクトストレージとブロックストレージの両方にCephを利用しています。ランドスケープマシンの/var/log/landscape/job-handler-1.logを見ると、次の100を超えるエラーが表示されます。 2015-03-05 21:18:38 '_get_nova_info'のINFOルートRetryingCallに失敗し、103回以上試行しました：2015-03-05 21:18:38 INFOルートトレースバック：：4つのnova-computeユニット / usrがありません/lib/python2.7/threading.py:783:__bootstrap /usr/lib/python2.7/threading.py:810:__bootstrap_inner /usr/lib/python2.7/threading.py:763:run --- <ここでキャッチされる例外> --- /usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:191:_worker /usr/lib/python2.7/dist-packages/twisted/python/context。 py：118：callWithContext /usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext /usr/lib/python2.7/dist-packages/storm/twisted/transact.py： 76：_wrap /opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py:751:_get_nova_info 注：デバッグ用の印刷ステートメントをいくつか追加したので、jobs.pyの行番号はオフになっています。これは、_get_nova_info（）関数の＃741行付近のアサートです（メモリが提供されている場合）。はい、今日のランドスケープppaの最新バージョンのランドスケープを信頼できるように使用しています。 そのため、/ opt / canonical / landscape / canonical / landscape / model / openstack / jobs.pyの_get_nova_info（）関数を変更して、nova_compute_hostnamesの長さを出力し、ゼロを取得しました。だから私はそれを/opt/canonical/landscape/canonical/landscape/model/openstack/region.pyのget_nova_compute_hostnames（）に追いかけて、self.juju_environment.get_computer_ids（）。count（）もゼロであることを発見しました。それで、私はself.juju_environment.has_computers（）への呼び出しを追加して、falseを取得しました。次に、self.juju_environment.get_juju_home（）を実行して、/ var / lib / landscape / juju-homes / 20。（はい、これは私のランドスケープボックスの2回目の再構築での20回目の試みです。私はしばらくの間この状態でいました）。それで、私は上記のjuju homeを利用してjujuステータスを実行しました、そしてすべてはよく見えました。5つのマシンとサービスすべてが開始され、保留状態やエラー状態はありませんでした。（4つのnova-computeノードを含む）何かアイデアはありますか？私はランドスケープ、MAAS、JUJU、およびpythonに少し慣れていないので、デバッグが少し遅くなります。 更新1： …