Issue during poolMember manipulation (offline and disable states)

[jrooty]

Environment

• Application Services Version: AS3 3.50
• BIG-IP Version: 15.X and 17.X

Summary

For a single AS3 call, when we add a new poolMember in 'active' state and change the current state for existing poolMember to 'offline' or 'disable', AS3 generates an issue.

Steps To Reproduce

Deploy first an application with only one poolMember

 "members": [
                    {
                        "servicePort": 80,
                        "adminState": "enable",
                        "ratio": 20,
                        "priorityGroup": 10,
                        "serverAddresses": [
                            "1.2.3.4"
                        ],
                        "shareNodes": true
                    }
                ],

Then POST a new declaration :

 "members": [
                    {
                        "servicePort": 80,
                        "adminState": "disable",
                        "ratio": 20,
                        "priorityGroup": 10,
                        "serverAddresses": [
                            "1.2.3.4"
                        ],
                        "shareNodes": true
                    },
                    {
                        "servicePort": 80,
                        "adminState": "enable",
                        "ratio": 20,
                        "priorityGroup": 10,
                        "serverAddresses": [
                            "1.2.3.5"
                        ],
                        "shareNodes": true
                    }
                ],

2. Observe the following error response:

{
            "code": 422,
            "message": "declaration failed",
            "response": "01020066:3: The requested Pool Member (/AP00086xPS2D/AP00086xPS2D_6b3ccf6680db_fastl4_tcp_443/P_fastl4_160924_1_svc_sg_paas_echonet_tcp_443 /Common/[1.2.3.5](http://1.2.3.5/) 80) already exists in partition AP00086xPS2D.",
            "host": "localhost",
            "tenant": "AP00086xPS2D",
            "runTime": 2195,
            "declarationId": "6d7ec3ee-36a5-4e40-a67b-9b9e98ebbfc9"
        },

Expected Behavior

Success.

Actual Behavior

To bypass this error, we have to introduce first the second member (in active state), then through a second AS3 call, disable the first member.

Thank you.

[sbarakett]

F5 version: '17.1.1.3',
as3: '3.52.0'

We are experiencing the same issue even while using the simplest of configs, no adminState, no priorityGroups, etc...

We get the same error, even if are not updating the pool. We deploy once, we update something else in the Virtual server not related to the pool, and we get the same error.

Workaround:
Even though node is shared, and is in the common partition, deleting and re-deploying the tenant, fixes the issue, even with the node in the common partition not changing. Deleting the tenant is not really an option.

This is our pool declaration that produces the same error,

            "pool-eks": {
                "class": "Pool",
                "loadBalancingMode": "least-connections-member",
                "members": [
                    {
                        "addressDiscovery": "static",
                        "servers": [
                            {
                                "address": "1.1.1.1%1",
                                "name": "ServerA"
                            },
                            {
                                "address": "1.1.1.2%1",
                                "name": "ServeB"
                            },
                            {
                                "address": "1.1.1.3%1",
                                "name": "ServerC"
                            }
                        ],
                        "servicePort": 443,
                        "shareNodes": true
                    }
                ],
                "monitors": [
                    {
                        "use": "tcp_443"
                    }
                ]
            },

[mdditt2000]

@jrooty @sbarakett please can you open a new SR for this issue. Please link the SR to the GitHub issue. TY.

[mdditt2000]

Closing issue out as request SR

[sbarakett]

I apologize for my ignorance, but I am not familiar with how to open an SR. If it was already opened can you please link it here. The bug is also documented in #868 which you left open.