Open Stack

Hi Michael,

thanks for taking the time reading this!

The internal octavia network is a vlan on a physical network on the 
hosts.
openstack --os-cloud admin subnet list --long gives:

+--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+
| ID                                   | Name                            
                    | Status | Project                          | State | 
Shared | Subnets                              | Network Type | Router 
Type | Availability Zones | Tags |
+--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+
...
| fe73f93f-9e76-4bd9-9ce4-e60882d313d9 | internal-octavia                
                    | ACTIVE | d52e2dccbc7e46d8b518120fa7c8753a | UP    | 
False  | fd10e49c-359a-45d0-b207-89ba3d438a68 | vlan         | Internal  
   | az-1, az-2         |      |
...
+--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+

so, Openstack seems to know the the network and it should work in both 
az.

openstack --os-cloud admin subnet list --long gives:
+--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+
| ID                                   | Name                            
                   | Network                              | Subnet        
      | Project                          | DHCP  | Name Servers | 
Allocation Pools                | Host Routes | IP Version | Gateway     
     | Service Types | Tags |
+--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+
...
| fd10e49c-359a-45d0-b207-89ba3d438a68 | 172_20_48_0_20                  
                   | fe73f93f-9e76-4bd9-9ce4-e60882d313d9 | 
172.20.48.0/20     | d52e2dccbc7e46d8b518120fa7c8753a | False |          
     | 172.20.48.50-172.20.63.254      |             |          4 | 
172.20.48.1     |               |      |
...
+--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+

BTW, starting an instance manually in the service project with the 
correct network and the octavia image works.

I recreated the availabilityzoneprofile via:

openstack --os-cloud service_octavia loadbalancer 
availabilityzoneprofile create --name az-1 --provider amphora 
--availability-zone-data '{"compute_zone": "az-1", "management_network": 
"fe73f93f-9e76-4bd9-9ce4-e60882d313d9"}'
openstack --os-cloud service_octavia loadbalancer 
availabilityzoneprofile create --name az-2 --provider amphora 
--availability-zone-data '{"compute_zone": "az-2", "management_network": 
"fe73f93f-9e76-4bd9-9ce4-e60882d313d9"}'

but still no success.

Am 2020-10-14 00:06, schrieb Michael Johnson:
> Hi Björn,
> 
> Yeah, I don't see a reason in that nova log snippet, so I can 't point
> to the exact cause. It might be higher in the logs than the snippet
> included.
> 
> That said, it might be that the AZ definition in the AZ profile does
> not include the appropriate lb-mgmt-net ID for az-2. Without that
> defined, Octavia will use the default lb-mgmt-net ID from the
> configuration file, which is likely only available in az-1. I would
> try defining the management_network and valid_vip_networks for az-2.
> 
> Michael