The requested Pool Member already exists in partition <name> when using shareNodes

[kingb33]

Environment

• Application Services Version: 3.52.0
• BIG-IP Version: 17.1.1.1

Summary

When creating a pool with a member that is defined in "servers" property, it results in an error message saying that the node exists in the Partition relating to the pool itself.

Steps To Reproduce

Steps to reproduce the behavior:

1. Submit the following declaration:

{
  "class": "AS3",
  "action": "deploy",
  "persist": true,
  "declaration": {
    "class": "ADC",
    "schemaVersion": "3.52.0",
    "id": "id",
    "label": "WebApp",
    "IAM": {
      "class": "Tenant",
      "Shared": {
        "class": "Application",
        "template":"shared"
      }, 
      "PROD": {
        "class": "Application",
        "myPool": {
          "class": "Pool", 
          "label": "Pool for myVS", 
          "members": [{"servers": [{"address": "1.1.1.1", "name": "localGateway"}], "servicePort": 161, "shareNodes": true}], 
          "remark": "Pool for myVS"
        }, 
      }
    }
  }
}

2. Submit the declaration a 2nd time
3. Observe the following error response:

 "The operation for IAM has returned code: 422 with the following message: 01020066:3: The requested Pool Member (/IAM/PROD/myPool /Common/localGateway 161) already exists in partition IAM."}

Expected Behavior

I have several other pools using this methodology using FQDN nodes and it doesn't cause issues.
For example, replace the pool with

        "myPool2": {
          "class": "Pool", 
          "members": [{"hostname": "slp-fram-003.stholdco.com", "servicePort": 8443, "addressDiscovery": "fqdn", "autoPopulate": true, "shareNodes": true}]
        }

If using this, you can re-issue the declaration and it will work.

Actual Behavior

You get the error from #3.

Work around

You can avoid this if you are okay with not naming your nodes. For example, if using "serverAddresses"

        "myPool": {
          "class": "Pool", 
          "members": [{"serverAddresses": ["1.1.1.1"], "servicePort": 161, "addressDiscovery": "static", "shareNodes": true}],
        }

[sbarakett]

May be related to bug #875

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

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.

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"
                }
            ]
        },

[eos500n2000]

Hi, want to let you know, we have reproed the issue in lab, and filed a bug ID for this issue.

Now, Workaround is

to use "serverAddresses" instead of "servers" for all the new added Pool Member.

"serverAddresses": [
"1.1.1.1"
],

------Instead of---------------------

"servers": [
{
"address": "1.1.1.1",
"name": "localGateway"
}
],

[sbarakett]

Hi, the workaround does not follow our standards naming conventions and standards, we will wait for the bug fix. Another work around is to delete the tenant and re-deploy, which also does fit our blue green strategy. Thank you, waiting for bug fix. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: eos500n2000 ***@***.***> Sent: Tuesday, October 22, 2024 12:38:22 PM To: F5Networks/f5-appsvcs-extension ***@***.***> Cc: sbarakett ***@***.***>; Comment ***@***.***> Subject: Re: [F5Networks/f5-appsvcs-extension] The requested Pool Member already exists in partition <name> when using shareNodes (Issue #868) Hi, want to let you know, we have reproed the issue in lab, and filed a bug ID for this issue. Now, Workaround is to use "serverAddresses" instead of "servers" for all the new added Pool Member. "serverAddresses": [ "1.1.1.1" ],

------Instead of--------------------- "servers": [ { "address": "1.1.1.1", "name": "localGateway" } ], — Reply to this email directly, view it on GitHub<#868 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADKOUD3D3CHF2JVL5ZFRYSTZ4Z5P5AVCNFSM6AAAAABMSVCWB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRZG42TOOJTGI>. You are receiving this because you commented.Message ID: ***@***.***>

[mbreton1]

Hi,
I am using version 3.53.0-7 and I still have the same issue. It was supposed to be resolved in this release but it is still not working for me.

[eos500n2000]

Hi, I am using version 3.53.0-7 and I still have the same issue. It was supposed to be resolved in this release but it is still not working for me.

As I know , this fix will be included in Dec.2024 release.