web-dev-qa-db-ja.com

フックが失敗しました:Juju / MAASと同じシステムでOpenStackを使用する場合、「shared-db-relation-changed」

1台のマシンを使用して14.04でOpenStackをセットアップしようとしています。 MAASをセットアップし、2台のマシンでJUJUを起動しました。1台はMAASに、もう1台はopenstackをセットアップしようとしているノードです。私はそれができると読んでいますが、基本的にこれを読んだ後に問題があります https://help.ubuntu.com/community/UbuntuCloudInfrastructure と掘りインターネットの周りでは、nova-volumeが非推奨であることがわかりました。そのため、代わりにcinderを使用しようとしています。

私はこれらのコマンドを使用しています:

juju deploy mysql --to 0
juju deploy rabbitmq-server --to 0
juju deploy --config=openstack.cfg keystone --to 0
juju deploy --config=openstack.cfg nova-cloud-controller --to 0
juju deploy --config=openstack.cfg cinder --to 0
juju deploy nova-compute --to 0
juju deploy glance --to 0
juju deploy openstack-dashboard --to 0

juju add-relation keystone mysql

juju add-relation nova-cloud-controller mysql
juju add-relation nova-cloud-controller rabbitmq-server
juju add-relation nova-cloud-controller glance
juju add-relation nova-cloud-controller keystone

juju add-relation cinder nova-cloud-controller
juju add-relation cinder mysql
juju add-relation cinder rabbitmq-server
juju add-relation cinder keystone

juju add-relation nova-compute mysql
juju add-relation nova-compute:amqp rabbitmq-server:amqp
juju add-relation nova-compute glance
juju add-relation nova-compute nova-cloud-controller

juju add-relation glance mysql
juju add-relation glance keystone

juju add-relation openstack-dashboard keystone

juju expose openstack-dashboard
juju expose nova-cloud-controller

ご覧のとおり、--to 0を使用して、すべてを同じノードに配置したいと言っています。私はすべてを始めることができますが、すべての関係をリンクした後、私はこのエラーを受け取ります:

hook failed: "shared-db-relation-changed"

また、そのユーザーとそのIPに対してアクセスが拒否されたことを示すエラーメッセージをログの1つに記録します。

問題は、jujuがIPが192.168.2.101であると他のサービスに伝えているのに、mysqlが127.0.0.1でユーザーを設定していること、つまり接続できないことだと思います。

何か案は?

他のもの:

  • これは、仕事でプライベートクラウドに使用され、半ダースほどのインスタンスが使用されることを期待しています。
  • 誰もが本番用ではないと言っているので、devstackは使いたくありません。
4
Tim Perry

コンテナ化せずに--toフラグを使用するのは本当に悪い考えです。この「ハルクスマッシング」に例えました。基本的には、すべてがマシンを所有することを期待する大量のサービスを互いに積み重ねます。

それでは、分離を達成し、それでもすべてを1台のマシンに保持するために何ができますか?コンテナ化!

--toフラグには細心の注意が必要です。これにより、壊滅的な衝突の可能性なしにコロケーションを実行できます。 --toは、--to lxc:0--to kvm:0などの構文をサポートします。これらの構文は、リストされているマシンのコンテナーにサービスを配置します。 OpenStackデプロイメントのほとんどすべてのチャームは、Cephとnova-computeを除き、LXC(またはKVM)コンテナーに安全に配置できます。 Nova-computeはそれ自体がVMをプロビジョニングするため(およびLXC内のKVMは奇妙です)、Cephはディスクを所有する必要があるためです。 Cephを使用せずにOpenStackデプロイメントを行うことができるので問題ありません。また、KVMをネストして、KVMでnova-computeを実行してKVM(またはLXC)を作成できます。

この時点ではパフォーマンスがすべてであり、このセットアップではそれほど多くは得られません。ただし、プロセスをパイロットするには十分なはずです。

7
Marco Ceppi