Let's have a look at your bundle. First of all, we need to ensure that we're both looking at the same file; from searching your config on Google I think I'm looking at:
(Please edit your question with the exact files you are deploying, it would help remove ambiguity)
At the end of every page of the charm store there is a list of each config option for every charm, so let's look at Keystone:
You can safely ignore the
annotations segment, all that is is X/Y coordinates of where to put the icon in the Juju GUI.
charm: cs:trusty/keystone-31 : This breaks down to "Revision 31 of the trusty (14.04) charm that is in the charm store."
num_units: This means you'll get 1 unit of Keystone. That means either one container or machine (which we'll see is defined later).
Ok, now the good bits, the options, these first two are pretty straightforward:
admin-password: (string) Admin password. To be used for testing
only. Randomly generated by default.
ha-mcastport: (int) Default multicast port number that will be used
to communicate between HA Cluster nodes.
This entry is ugly due to formatting, so I'll replicate it here:
openstack-origin: (string) Repository from which to install. May be >one of the following:
ppa:somecustom/ppa, a deb url sources entry, or a supported Cloud
Archive release pocket.
Supported Cloud Archive sources include:
For series=Precise we support cloud archives for openstack-release: *
icehouse For series=Trusty we support cloud archives for
openstack-release: * juno * kilo * ...
NOTE: updating this setting to a source that is known to provide a
later version of OpenStack will trigger a software upgrade. NOTE: when
openstack-origin-git is specified, openstack specific packages will be
installed from source rather than from the openstack-origin
I get the feeling you want to keep that as a default for now.
Here's where I think you're asking for clarification (please edit your question if this is not the case):
Ok, so what does that mean? Well let's look at the top of the bundle:
In this section we are declaring the machines on the cloud, that means we are asking for 0-3 machines, for a total of 4. Each part of that bundle has a
to: section. That means we are telling Juju exactly where you want a unit to go.
In this case
to: lxc:3 means, put keystone in an LXC container on machine number 3.
As another example, look at where we put Ceph:
lxc: there, that means, no container, just put ceph on machines 1,2, and 3. And let's look at `ceph-radosgw:
That means put ceph-radosgw on machine 0, in a container.
So why do we do this? Well, some services don't need to be everywhere, it depends on the use case, if you want a denser cloud then this bundle is probably what you want. If you're testing out openstack then getting an operational prototype on four machines is desirable. If you want to go with larger capacity, then you can feel free to edit the bundle, remove all the
to: statements you see, and Juju will just ask MAAS for one machine per service; this will take up more machines though.