Openstack-bundle config/underlying model


#1

Hej,

I really like Juju/MAAS combo, its handy. Hope this is not considered off-topic, or TL;DR. But I have a question, of practical nature.
I’ve used the openstack-bundle to do several test deployments; some issues have however popped up. For instance, the nova-compute libvirt-image-backend is undefined, should be set to rdb, its easy to fix (juju config…) but unless you dug into it, you end up with just local storage on the compute nodes (and an unused ceph deployment, afaik).
My current issue, when the bundle is deployed all nodes and containers are attached to the deployment network that MAAS uses. I’ve setup the physnet1:br-ex:eno2 so, that openstack VMs can get IP, and floating IP are also working. However, I’d like to separate MAAS/juju orchestration traffic from ‘model’ traffic, so VLANS/Subnets are created to carry this.
From juju config, the os-[admin|internal|public]-network variables are present; but how are they tied/mapped to the underlying network? is this supposed to be done via a physnetX:br-y: mapping? In that case, how would the containers be attached to these? As I did not find some obvious matching variable, I guessed that the nodes would just attach once the networks were present on the nodes, i.e. configuring it via MAAS prior to deployment. Sadly, that did not work, the only thing that happened was that nothing worked properly :slight_smile: and when I investigated, all containers remained on the original network. Can anybody shed some light on how this is supposed to be done?

BR/Patrik


#2

Howdy @pal-arlos, using Juju with MAAS for openstack generally entails using the spaces data to setup various spaces you’ll use to model the network you want. Once the spaces are defined in MAAS, maybe one for management communication, one for storage traffic, etc, you’d then be able to deploy your OpenStack bundle binding the different application endpoints to the right spaces. In the containers context this would make sure that the network devices in the container are able to go across a device that can speak on the right spaces. There’s some Juju docs around using spaces and binding things to those spaces can be found here:

https://docs.jujucharms.com/2.4/en/network-spaces
https://docs.jujucharms.com/2.4/en/charms-deploying-advanced#deploying-to-network-spaces

If you have specific OpenStack setup questions the OpenStack charming community is great about how to set things up in that world. They live over in the OpenStack community over here:
https://docs.openstack.org/charm-guide/latest/find-us.html

Hope that helps!


#3

Hej @rick_h,

It helped a quite alot, and I’m reaching out to the OpenStack Charming community, for the specifics regarding it.

However, a general question wrt. charms/bundles & spaces. As I understood it, the spaces used used in a charm, or bundle, should be identified via the ‘binding’ or possibly ‘extra-binding’ statement. If identified via ‘binding’ the spaces are required for deployment, while ‘extra-binding’ would be ‘if-present-then-use’.

Is there any simple way to identify what spaces are used by a bundle/charm, or is the current path to manually going through the bundle./metadata.yaml’s?

BR/Patrik