Fake members operating_status ONLINE

Bug #2034522 reported by Fernando Royo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
Fernando Royo

Bug Description

I can deploy members with an invalid / invented ip address (no real servers with that address) and the LB shows that everything is ok with them (running `openstack loadbalancer status show <lb>` will show that the members have "operating_status": "ONLINE".

An example: I deployed the following:
{
    "loadbalancer": {
        "id": "c50b7cb3-6b8f-434b-9a47-a10a27d0a9b5",
        "name": "ovn_lb",
        "operating_status": "ONLINE",
        "provisioning_status": "ACTIVE",
        "listeners": [
            {
                "id": "87bafdda-0ac6-438f-8824-cb75f9e014df",
                "name": "tcp_listener",
                "operating_status": "ONLINE",
                "provisioning_status": "ACTIVE",
                "pools": [
                    {
                        "id": "aa6ed64c-4d19-448b-969d-6cc686385162",
                        "name": "tcp_pool",
                        "provisioning_status": "ACTIVE",
                        "operating_status": "ONLINE",
                        "health_monitor": {
                            "id": "cc72e7eb-722b-49be-b3d2-3857f880346d",
                            "name": "hm_ovn_provider",
                            "type": "TCP",
                            "provisioning_status": "ACTIVE",
                            "operating_status": "ONLINE"
                        },
                        "members": [
                            {
                                "id": "648b9d51-115a-4312-b92e-cc59af0d0401",
                                "name": "fake_member",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "10.100.0.204",
                                "protocol_port": 80
                            },
                            {
                                "id": "8dae11a2-e2d5-45f9-9e85-50f61fa07753",
                                "name": "de3f2a06",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "10.0.64.34",
                                "protocol_port": 80
                            },
                            {
                                "id": "9b044180-71b4-4fa6-83df-4d0f99b4a3f7",
                                "name": "fake_member2",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "10.100.0.205",
                                "protocol_port": 80
                            },
                            {
                                "id": "fe9ce8ca-e6b7-4c5b-807c-8e295156df85",
                                "name": "6c186a80",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "10.0.64.39",
                                "protocol_port": 80
                            }
                        ]
                    }
                ]
            }
        ]
    }
}

when the existing servers are the following:
+--------------------------------------+-----------------+--------+----------------------------------------------------------+----------------------------------------------------+------------+
| ID | Name | Status | Networks | | |
+--------------------------------------+-----------------+--------+----------------------------------------------------------+----------------------------------------------------+------------+
| 1e4a4464-4bbf-4107-94e4-974e87c31074 | 8941a208 | ACTIVE | private=10.0.64.34, fd47:e41c:f56e:0:f816:3eff:fe9f:67f4 | | |
| 1a0de4d2-d9ea-4d60-85ff-018bcc00d285 | tobiko_44801dfe | ACTIVE | private=10.0.64.39, fd47:e41c:f56e:0:f816:3eff:fea2:7af9 | | |
+--------------------------------------+-----------------+--------+----------------------------------------------------------+----------------------------------------------------+------------+

it happened to me a few times that I had typos when I created the member (I wrote the ip address wrong), seeing those members as ONLINE, it would have been much more difficult to me to understand what happened.

Changed in neutron:
assignee: nobody → Fernando Royo (froyoredhat)
status: New → Confirmed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (master)
Changed in neutron:
status: Confirmed → In Progress
yatin (yatinkarel)
Changed in neutron:
importance: Undecided → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (master)

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

commit fe6612f71475413b64e554b9a6707e35e9e5c053
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (stable/2023.1)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (stable/zed)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (stable/yoga)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (stable/xena)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ovn-octavia-provider (stable/wallaby)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/ovn-octavia-provider 5.0.0.0rc1

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (stable/2023.1)

Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/894925
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/18deb91872bc0c04523beaeadcebe789f65c2424
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit 18deb91872bc0c04523beaeadcebe789f65c2424
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Conflicts:
          ovn_octavia_provider/tests/unit/test_helper.py

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
    (cherry picked from commit fe6612f71475413b64e554b9a6707e35e9e5c053)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (stable/xena)

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

commit 3c6cb5a165b50eb6d21fbe87c427a66897a6dbf2
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Conflicts:
          ovn_octavia_provider/tests/unit/test_helper.py

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
    (cherry picked from commit fe6612f71475413b64e554b9a6707e35e9e5c053)

tags: added: in-stable-xena
tags: added: in-stable-wallaby
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (stable/wallaby)

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

commit d37821d78ae9492450b70965a52a9a465e5808b3
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Conflicts:
          ovn_octavia_provider/tests/unit/test_helper.py

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
    (cherry picked from commit fe6612f71475413b64e554b9a6707e35e9e5c053)

tags: added: in-stable-yoga
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (stable/yoga)

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

commit 10f22e8f885bc98e2951502e5dc268639c8d4052
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Conflicts:
          ovn_octavia_provider/tests/unit/test_helper.py

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
    (cherry picked from commit fe6612f71475413b64e554b9a6707e35e9e5c053)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ovn-octavia-provider (stable/zed)

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

commit eaf7c3efff666e185584475ef9db286699fcf839
Author: Fernando Royo <email address hidden>
Date: Wed Sep 6 09:50:19 2023 +0200

    Cover the use case of a member non existing

    When a HM is attached to a pool and a backend member in that pool
    is a fake member (e.g. due to a typo on creation) the member remains
    in ONLINE status. Basically this is due to the fact that there
    isn't any LSP attached to that member and no Service_Monitor entries
    will take care of it.

    This patch checks inmediatelly after creation the member and update
    the whole LB status to reflect this fake member that could help to
    the user to identify quickly those fake members.

    Conflicts:
          ovn_octavia_provider/tests/unit/test_helper.py

    Closes-Bug: 2034522
    Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
    (cherry picked from commit fe6612f71475413b64e554b9a6707e35e9e5c053)

tags: added: in-stable-zed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/ovn-octavia-provider yoga-eom

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/ovn-octavia-provider 3.1.2

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/ovn-octavia-provider wallaby-eom

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/ovn-octavia-provider xena-eom

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.