1

I'm new to MaaS, Juju and Openstack so please bear over with me.

My questions is:

When I try to deploy the openstack-base in juju-gui, it creates 4 nodes with the names: new0, new1, new2 and new3. It also creates containers and all the other stuff like relations.. Which is nice! But.. Why doesn't it use my already deployed machines or the machines with status ready? And how can I connect one of these "new" juju machines with my MaaS Machines?

The 4 new machines is only visible in the juju-gui and not in juju status nor MaaS. I simply don't know how to "feed" it with the necessary machines without moving services and deploying everything manually.

3
+200

"Why doesn't it use my already deployed machine...?"

If something is previously deployed then Juju won't necessarily re-use it since the default is often one-service-per-node (installing to the "root" container, if you will). You can, though, install into LXC containers and co-locate services on the same node which is likely what that bundle is doing.

"Why doesn't it use my other nodes with Ready status...?"

The scheduler will select four nodes which have the correct architecture (Trusty, for example) and if the bundle has memory and/or processor requirements this also might filter which nodes it uses.

You might give all this some time. Typically, it seems to go fast at first and will show up visually in the juju-gui console and still it's grinding away if you're watching "juju status" or "juju debug-log" to see what's going on.

After you have the stack up and running and juju status reports that everything is running (versus "pending" or "allocating" or whatever) then you're expected to add some nova-compute nodes, say, with a "juju add-unit nova-compute" perhaps.

In order to ssh into some of these nodes you'll want to make sure that you go into the MAAS console and add a keypair for this. Then from your controller, perhaps, you would do "ssh ubuntu@nodename.domain" and credential using the shared secret from the keypair generation. Once you're in that session with the node you could visit the /var/log/maas and /var/log/juju folders and review the logs there--they usually have the best insight into how your deployment went.

So the commissioning logs are basically the pre-charms stuff related to MAAS itself and not necessarily useful at this step. They're the ones with /var/logs/maas/cloud.log in their file naming. The deployment logs are more of what you should be after at this step. They'll be the ones in the /var/log/juju folder like "unit-CHARMNAME-0.log" and these you can watch in realtime while the deployment is happening.

One big annonyance is that your ~/.ssh/known_hosts file will need to be managed as you deploy/delete/re-deploy the same nodes since they'll get new IP addresses. To ssh this looks like a security problem. You'll need to manually run pairs of commands like:

ssh-keygen -R nodename.domain
ssh-keygen -R 192.168.0.22

...when that "nodename" node has been re-deployed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.