Hi Phil,
I don’t fully understand what you are trying to do, but hopefully, this will provide some more info/context.
MAAS can only really deploy physical or virtual machines. If you are using a KVM pod, MAAS will allow you to create a VM that would just become like any machine in MAAS. However, MAAS can not do the same with LXD and containers. Please also note that 2.5b2+ will allow you to chose any physical machine in MAAS and convert it into a Pod (e.g. MAAS will deploy the machine with Ubuntu bionic, install/configure KVM/libvirt/etc, and add it to MAAS as a KVM pod).
That said, in the context of Juju, MAAS simply provides instances to Juju, which Juju will use to put applications on. For Juju, it doesn’t really matter whether the instance that MAAS provided is a physical system or a virtual machine (that for e.g., was automatically created from a KVM pod). However, you as an administrator may provide constraints to request an instance that better suits your needs. Furthermore, (again, in the context of MAAS) Juju can also place a service/application inside a LXD container, inside an instance/machine you have already deployed (with Juju) - note that Juju can also do other fancy stuff with Juju directly, but we are just talking in the context of MAAS.
Example 1
To provide a more practical example, this is what I have done:
- maas00 → Machine (physical) where MAAS is running
- node04 → Machine (physical) I enlistment/commissioned/deployed with MAAS
- I deployed node04 and made it a KVM pod
- I added a tag to node04 KVM pod (e.g. test-tag).
Now, I’m doing to bootstrap my environment, and I’m going to put the controller on a virtual machine inside the node04 KVM pod. I can do this with:
ubuntu@maas00:~$ juju bootstrap maas maas-controller \
--credential admin \
--bootstrap-constraints "tags=test-pod mem=4000 cores=2"
Creating Juju controller "maas-controller" on maas
Looking for packaged Juju agent version 2.4.4 for amd64
Launching controller instance(s) on maas...
- ecyxhe (arch=amd64 mem=3.9G cores=2)
Installing Juju agent on bootstrap instance
Fetching Juju GUI 2.14.0
Waiting for address
Attempting to connect to 10.90.90.21:22
Connected to 10.90.90.21
Running machine configuration script...
Bootstrap agent now started
Contacting Juju controller at 10.90.90.21 to verify accessibility...
Bootstrap complete, "maas-controller" controller now available
Controller machines are in the "controller" model
Initial model "default" added
With the above, Juju asked MAAS for a machine with 2 cores, 4 gigs of ram and tagged as ‘test-pod’. Since no physical machine was found with those constraints, but the pod does because its tagged as ‘test-pod’ (and has available resources) then it automatically creates a VM with the requested CPU/Mem and deploys it with Ubuntu.
Note that you can just the same type of constraints when deploying a service (with --constraints rather than bootstrap-constraints, but I used it as an example).
Example 2 - Putting applications inside a container
Now, since we want to put services inside containers inside a physical machine, I’ll do so with Juju. There are various ways of doing it, but I’ll chose an approach to explain an example. For this, I’ll use node06.maas (which I just added to my MAAS for this example). To do so, I do:
juju deploy ubuntu --to node06.maas
What the above does is uses the ‘ubuntu’ charm to deploy it in node06. This could have been any other application/charm. Once completed, we see something like:
ubuntu@maas00:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
default maas-controller maas 2.4.4 unsupported 03:16:25Z
App Version Status Scale Charm Store Rev OS Notes
ubuntu 18.04 active 1 ubuntu jujucharms 12 ubuntu
Unit Workload Agent Machine Public address Ports Message
ubuntu/0* active idle 0 10.90.90.22 ready
Machine State DNS Inst id Series AZ Message
0 started 10.90.90.22 estbnr bionic default Deployed
Now, I want to put another service/application inside the machine I just deployed, which is machine 0. I can do this with:
ubuntu@maas00:~$ juju deploy ubuntu ubuntu2 --to lxd:0
What the above does is deploy another instance of the same ‘ubuntu’ charm/application to a container inside machine 0, and this results in:
ubuntu@maas00:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
default maas-controller maas 2.4.4 unsupported 03:26:36Z
App Version Status Scale Charm Store Rev OS Notes
ubuntu 18.04 active 1 ubuntu jujucharms 12 ubuntu
ubuntu2 18.04 active 1 ubuntu jujucharms 12 ubuntu
Unit Workload Agent Machine Public address Ports Message
ubuntu2/0* active idle 0/lxd/0 10.90.90.23 ready
ubuntu/0* active idle 0 10.90.90.22 ready
Machine State DNS Inst id Series AZ Message
0 started 10.90.90.22 estbnr bionic default Deployed
0/lxd/0 started 10.90.90.23 juju-04fb1d-0-lxd-0 bionic default Container started
** NOTE **: If you are wondering what’s the difference between ubuntu and ubuntu2, these are just different (instances of the) applications, which is similar to doing this:
juju deploy ceph ceph-storage-cluster-1 -n 4
juju deploy ceph-osd ceph-osd-1
juju add-relation ceph-storage-cluster-1 ceph-osd-1
juju deploy ceph ceph-storage-cluster-2 -n 5
juju deploy ceph-osd ceph-osd-2
juju add-relation ceph-storage-cluster-2 ceph-osd-2
… which means two different clusters.
Example 3
Lastly, instead of doing example 2 above, you could just have simply done this:
juju deploy ubuntu --to lxd
The above simple requests a machine from MAAS (any random machine because I didn’t pass constraints, which could have also been a VM from inside a pod), and installs the application/charm inside a container.
ubuntu@maas00:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
default maas-controller maas 2.4.4 unsupported 03:57:57Z
App Version Status Scale Charm Store Rev OS Notes
ubuntu 18.04 active 1 ubuntu jujucharms 12 ubuntu
Unit Workload Agent Machine Public address Ports Message
ubuntu/1* active idle 1/lxd/0 10.90.90.23 ready
Machine State DNS Inst id Series AZ Message
1 started 10.90.90.22 estbnr bionic default Deployed
1/lxd/0 started 10.90.90.23 juju-04fb1d-1-lxd-0 bionic default Container started
So what’s the difference? In example 2 I deployed a charm/application inside a physical machine and took advantage of it to deploy other services/charm/applications inside containers inside that machine. In this example, however, I simply requested to put my service in a new machine inside a container (so there’s really just 1 application, not 2).
Hope this helps clarify things a bit.
PS. I am by no means a Juju expert nor a day to day operator of it, so I will try help as much as possible. But if you are wondering or wanted to ask more advanced Juju questions, we also have this discourse: https://discourse.jujucharms.com/
