"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 [email protected]" 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.
