In the case of OpenStack, most of the charms support config options to bind specific services to specific networks.
So, you can: * run a base script to bind the network interfaces you need to the networks / vlans you want * set the config per charm manually ... which works, and it's how we do complex telco-style OpenStack deployments, but it requires a handy piece of paper to remember what you want where, and configure all 24 services correctly. The work Dimiter is describing will mean you can do it much more simply: * tell MAAS about each of the network spaces you care about * juju deploy with a parameter that binds the service to the network space All the magic will then Just Work, both for bare metal and container workloads. We're not far from that now. Note that charms will need to know about this; the OpenStack ones will quickly support it (because that's how we'd like to use them too) but it will take time for other charms to get updated to look at the network model. Till they do, they will typically bind to all the interfaces they see. In the common case, they will only need one interface, and it will be on the right network, but in complicated cases where they want to offer different services on different networks the charm will need to know about the network model. Mark -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
