Open Stack

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 at 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
>