I see. Please take a look at this enlightening Discourse post to introduce yourself to the concept of Juju spaces, how they are mapped with MAAS spaces, and how they can be declared to interface bindings.
Assuming that you have figured out the desired network topology for your OpenStack, you have to:
- infra-wise: connect your machines appropriately
- enlist your machines in MAAS
- (optional) pre-configure your MAAS machines with any extra network/storage configuration
- declare your MAAS spaces by adding the relevant subnets to them (i.e.,
172.28.0.0/16goes to spaceexternal,192.168.0.0/24goes to spacepxe, etc.). Also include any subnets you have declared in any VLAN. In general this is the time when you are declaring your soon-to-be-created OpenStack networking. - Ensure that your spaces are loaded in Juju, and if not, re-load them - link.
- Ask Juju to deploy OpenStack charms, relate them, and provide bindings for both sides of the relation.
Juju will make sure that:
- It will place application units only on machines that their networking includes all the spaces defined in the application bindings of the units’ applications.
- It will create containers for containerized application units only on machines with networking that includes all the application bindings of the units’ applications.
- It will make sure that application units that are integrated with bindings will use only their addresses that corresponds to subnets that are part of the spaces of the bindings. This one is taken care by the charm implementation logic though, not directly by Juju.
I cannot advise you on the networking side of things, so this is yours to investigate. But with the mechanism described above, you can make sure that Juju understands your intentions for the networking and tries to deploy OpenStack in the way you are expecting it to do. As for package download during deployment, you can also consider setting MAAS as a proxy, which is the default configuration - link.