[ovn-octavia-provider] Do not make the status of a newly HM conditional on the status of existing members

[Fernando Royo]

When a new HM is created for a LB (ovn-provider), it is checking the member status, if any of the member (ports related) is not found the HM is created with ERROR provisioning status. It doesn't make sense if we take into account that the HM is an independent entity and should not see its status conditioned by the status of the members it will monitor.

In fact, this behaviour only occurs if we follow these steps secuen:

- Creation of a pool (pool1)
- Creation of a member (member1) associated to the previous pool (pool1), which starts in ACTIVE
- Creation of a member (member2) associated to the previous pool (pool1), which starts in ERROR status for example because we have invented the member address.
- Creation of a HM associated to the pool (pool1)

as output the HM will be in ERROR.

If we do the same steps in a bulk request the output will be HM as ACTIVE and the members as expected (member1 ACTIVE, member2 ERROR)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868092

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868092
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4
Submitter: "Zuul (22348)"
Branch: master

commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4
Author: Fernando Royo <email address hidden>
Date: Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses

    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.

    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.

    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868388

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868389

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868410

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868411

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868388
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/21d8f7cc7f6ce0692abc9fe25c4cbeb6faa966a1
Submitter: "Zuul (22348)"
Branch: stable/zed

commit 21d8f7cc7f6ce0692abc9fe25c4cbeb6faa966a1
Author: Fernando Royo <email address hidden>
Date: Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses

    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.

    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.

    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361
    (cherry picked from commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868389
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/509941c6a507872bd6b84ec19cee449e452457af
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 509941c6a507872bd6b84ec19cee449e452457af
Author: Fernando Royo <email address hidden>
Date: Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses

    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.

    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.

    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361
    (cherry picked from commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868411
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/3a505ed7b6ba2e9085dcc4089448df82b301185a
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 3a505ed7b6ba2e9085dcc4089448df82b301185a
Author: Fernando Royo <email address hidden>
Date: Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses

    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.

    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.

    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361
    (cherry picked from commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868410
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/fb5b0bd519ff85ad63a59944911b9cd8fef1704a
Submitter: "Zuul (22348)"
Branch: stable/xena

commit fb5b0bd519ff85ad63a59944911b9cd8fef1704a
Author: Fernando Royo <email address hidden>
Date: Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses

    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.

    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.

    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361
    (cherry picked from commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ovn-octavia-provider 1.2.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ovn-octavia-provider 4.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ovn-octavia-provider 2.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ovn-octavia-provider 3.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ovn-octavia-provider wallaby-eom release.