Object updates which do not require loadbalancer provisioning status updates should unblock the provisioning status of loadbalancer objects.

[jgruber]

Agent Version

9.3.1b

Operating System

CentOS 7.3

OpenStack Release

Mitaka

Bug Severity

3. Severity 3 (Medium) : Defect is causing intermittent errors in system operations.

Description

The community LBaaSv2 code sets the parent loadbalancer object provisioning status to 'PENDING_UPDATE' for all updates of dependent objects.

    # if the model passed in is not a load balancer then we will
    # set its root load balancer's provisioning status to
    # PENDING_UPDATE and the model's status to the status passed in
    # Otherwise we are just setting the load balancer's provisioning
    # status to the status passed in
    if db_lb_child:
        db_lb.provisioning_status = constants.PENDING_UPDATE
        db_lb_child.provisioning_status = status
    else:
        db_lb.provisioning_status = status

Particularly in the create member method, one which needs to be called repeatedly to support pools of any size, if the previous create or update method has not updated from the agent, the next call will error with and StateInvalid method. This will show up in the neutron server log with:

Invalid state PENDING_UPDATE of loadbalancer resource [loadbalancer id]

If the create or update call of the a object associated with the loadbalancer does not change the status of the loadbalancer itself, we should immediately fix the provisioning state of the loadbalaner to unblock future calls.

The immediate need is for pool members. We should consider it on listeners, pools, and pool members.

Deployment

neutron lbaas-loadbalancer-create --name test_lb_member_test [subnetid]
neutron lbaas-pool-create --loadbalancer [lbid] --name test_lb_member_test_pool --lb-algorithm ROUND_ROBIN --protocol TCP

create 50 pool members in a loop. You'll get the error almost immediately.