Openstack neutron linuxbridge help

framework
1

Hi All

I’ve been trying to build a neutron-api subordinate for setting up Linuxbridge-agent
I’ve been following the example guide for openstack ussuri https://docs.openstack.org/neutron/ussuri/install/controller-install-option2-ubuntu.html

my repo: https://gitlab.com/grami.moss/neutron-plugin-api-linuxbridge which I’m using the reactive setup.

I’m wanting have this charm install different packages and start services based on the parent charm.

for example:
if
neutron-api/0
neutron-api-linuxbridge/0
then
install package1, package2 and package3
start service1, service2 and service3
but if
nova-compute/0
neutron-api-linuxbridge/0
then
install package1
start service1

It’s mainly just how to write the how to figure out which parent is linked?
once I know I can do this I can finish off the config files and the rest of the config options.

any help would be great.

2

@openstack-charmers would you mind giving some pointers maybe?

3

Hello Graeme,

Welcome to the Juju community and thank you for your interest in the OpenStack charms.

First off I would like to ask you if you have a specific use case behind the wish for writing a charm for the Neutron linuxbridge driver? It is getting quite vintage and I’m not sure about the state of support for it in the upstream Neutron code base.

I see you have found the linuxbridge driver referenced in the upstream install Neutron on Ubuntu docs and all I can say is that unfortunately they look a bit dated. If you want updated documentation on installation of OpenStack with the charms you can take a look at the OpenStack Charms Deployment Guide.

On to your charming question:
For how to detect which principle charm your subordinate charm is related to I would use different endpoints/interfaces. That will allow your subordinate charm to know for sure what is in the other end. Both the neutron-api and the nova-compute provide subordinate relations and use different interfaces that you can consume from your subordinate charm.

As for the duality you propose in your charm I would not recommend that approach.

The purpose of the subordinate charm you deploy with neutron-api is very different from the purpose of the subordinate charm you deploy along with nova-compute.

4

Hi Frode

Thank you so much for the response.

The reason I have been looking at the linuxbridge been simply down to vlan-transparency as OVS and OVN do not support vlan-transparency. Linuxbridge is the only supported driver.

Some background:
I’ve been tasked to create an openstack lab for https://www.quali.com/products/cloudshell-pro/ the openstack lab will host network switches and routers and requires vlans to be transparent from the provider side.

I totally understand that in general not may people/companies would require this, but until OVN supports vlan-transparency I’m stuck with trying to get openstack to use linuxbridge driver.

On the charm I was hoping to use one charm to rule them all but what you have said is starting to make more sense. I’ll look at two separate charms and use a relation between them to share settings to make sure nova-compute is not effected with neutron-api-subordinate.

I was looking at the principal_unit in the charmhelpers and them placing this in the charms_openstack.charm.OpenStackCharm to add if the principal is contains neutron.
again looking at what you saying it would cause problems.


parent = principal_unit().split('/')[0]
if 'neutron' in parent:
    extra_pkgs = ['neutron-plugin-ml2',
                'neutron-l3-agent',
                'neutron-dhcp-agent',
                'neutron-metadata-agent']
    packages.extend(extra_pkgs)
        
    extra_serv = [
            'neutron-l3-agent',
            'neutron-dhcp-agent',
            'neutron-metadata-agent'
        ]
    services.extend(extra_serv)

thanks again for the reply I have some thinking to do and will have to create another charm.

5

Just an update if any does look at this. Ussuri has marked linux bridge as deprecated not great as I remember 2019 STG summary stated linux bridge is not going any where.

A brighter side is that they are working on OVN to support vlan transparency which could help people move away from linux bridge.