Yeah, it's clearly a nova scheduling issue as we can see in the nova logs that Octavia passed in the correct AZ setting.
Is there any way you can make the full chunk of the nova scheduler log available? Somewhere in there should be a filter log message that indicates why nova is unable to schedule this correctly.
It might also be a good idea to ask this again on the discuss list and tag nova (Add [nova] in the subject) instead of Octavia.
Michael
On Wed, Oct 14, 2020 at 9:50 AM bjoernputtmann@netprojects.de wrote:
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