On the installation screen I selected the “Multiple server install with MAAS” option, selected “Create a new MAAS on this server”, and followed the defaults from there. Toward the end of the install I was given an address through which I could view the MAAS control panel, 10.0.2.5. Needless to say I was pretty excited. Of course, the address didn’t work and I quickly realized that I couldn’t actually access that network. Reviewing the Networking settings for the VM I made the following changes:
Attached to: Bridged Adapter Name: eth0 Promiscuous Mode: Allow All
I updated each unit to reflect these settings. After the update, I had to re-start the VM and reconfigure MAAS to use the new address. This was done simply with:
sudo dpkg-reconfigure maas |
Then I updated the IP to reflect the new IP address within my network. After doing so 192.168.5.27 became my MAAS Master, and http://192.168.5.27/MAAS loaded the control panel!
Taking notice of what the Dashboard says, I ran the following two commands:
sudo maas createsuperuser sudo maas-import-isos |
The first command prompted me for a user, password, and email. The second ran for several minutes downloading and creating different precise images. Once that was finished, my dashboard still showed warnings of impor-isos, but more importantly I was able to log in and see that I had 0 nodes!
This gave me the confidence to push forward. I started the “maas1″ VM to begin the install process. Like before, I selected “Multiple server install with MAAS”. The next screen provided the option to Enlist with the maas-master MAAS Server, so I happily selected that option when the machine suddenly SIGKILLs all processes then powers off. The victory was in the dashboard though, as it now reflected 1 node!
I continued doing this for each of the “maas” VMs until all were registered in the maas-master dashboard. Unfortunately, during installation, of one of the nodes lost my naming scheme (I was trying to do maas-node0, maas-node1, … for each MAAS node) and ended up naming one of the maas2, which threw off the naming for the rest of the nodes. That aside, all of the initial nodes I wanted to enlist did so without any issues.
Now it was time to get some Juju goodness pushing against these machines. The first thing I did was hunt down my MAAS Key. I stumbled through a few sections of the dashboard before landing in the account preferences. I also noticed a section for SSH Keys which I added my public key to (for good measure). I copied my MAAS Key and created the following stanza in my juju environments file (I couldn’t find documentation on the Juju site for MAAS setup but I found this URL from a screenshot of MAAS testing tools, which lead me to the answer).
environments: vb-maas: type: maas maas-server: http://192.168.5.27:80/MAAS maas-oauth: "MY:MAAS:KEY" admin-secret: super-secret-made-up-admin-key default-series: precise |
After doing that, boot each VM and the PXE DHCP should find your MAAS Master and set up the VM properly. Each machine will turn off after successful setup and MAAS Dashboard will update. The end result is quite glorious:
Now it’s really time to get Juju working with these lovely MAAS machines! After several non-starts I created a new account in MAAS Dashboard with the same username as my local user and updated Juju environments to use that MAAS Key. After completing that, I issued a bootstrap:
juju bootstrap |
and checked the dashboard after the command completed.
The dashboard now shows one of the nodes allocated to Juju for bootstrapping. I had to manually start each VM, as for some reason they don’t respond to Wake On Lan. However, my goal of using Juju to deploy to MAAS was fulfilled. There is definitely room for improvement with the experience, but I have high hopes when we start throwing bare metal at MAAS.