AS3 fails with unspecific error when an external data group externalFilePath has an invalid HTTP response code

[megamattzilla]

Environment

• Application Services Version: 3.30.0
• BIG-IP Version: 15.1.x

AS3 fails with unspecific error when an external data group externalFilePath has an invalid HTTP response code

Steps To Reproduce

Steps to reproduce the behavior:

1. Submit the following declaration:

{
  "class": "AS3",
  "action": "deploy",
  "persist": true,
  "loglevel": "debug",
  "declaration": {
    "class": "ADC",
    "controls": {
      "trace": true,
      "logLevel": "debug"
       },
    "schemaVersion": "3.29.0",
      "Common": {
        "class": "Tenant",
        "Shared": {
          "class": "Application",
          "template": "shared",
          "header_to_pool": {
                        "class": "Data_Group",
                        "storageType": "external",
                        "keyDataType": "string",
                        "externalFilePath": "https://raw.githubusercontent.com/megamattzilla/this/does/not/exist",
                        "ignoreChanges": true,
                        "separator": ":=",
                        "label": "header_to_pool"
                    }
          }
        }
      }
    }

2. Observe the following error response:

    "results": [
        {
            "code": 200,
            "message": "success",
            "lineCount": 16,
            "host": "localhost",
            "tenant": "Common",
            "runTime": 3237
        },
        {
            "code": 422,
            "message": "declaration failed",
            "response": "Failed! exit_code (22).\n",
            "host": "localhost",
            "tenant": "Common",
            "runTime": 3289
        }
    ]

Expected Behavior

An error stating the URL returned a 404 response code for data group header_to_pool

Actual Behavior

An unspecific error is observed. When submitting a declaration with a large amount of elements it can be very difficult to pinpoint an issue such as one externalFilePath returning an invalid HTTP response code.

Also, why are two responses given (200 and 422)?

[dstokesf5]

Thank you for your feedback. I have added this to our internal product backlog as AUTOTOOL-2980.

[dstokesf5]

There are two responses because the Common partition is processed as two separate partitions to facilitate object sharing between tenants. One part was successful, the other was not.

[megamattzilla]

quick question @dstokesf5 on the two response codes- I noticed in a successful AS3 declaration to /Common/Shared they both say tenant Common. Should one say Shared?

[
    {
        "code": 200,
        "host": "localhost",
        "lineCount": 123,
        "message": "success",
        "runTime": 50857,
        "tenant": "Common"
    },
    {
        "code": 200,
        "host": "localhost",
        "lineCount": 65,
        "message": "success",
        "runTime": 47822,
        "tenant": "Common"
    }
]

[dstokesf5]

No, they should both say Common. In this case, Shared is the name of the AS3 application.

[megamattzilla]

I saw notes in AS3 3.35.0 that this issue was fixed.

How was it fixed? I'm seeing the same behavior in AS3 3.35.0.

{
    "version": "3.35.0",
    "release": "4",
    "schemaCurrent": "3.35.0",
    "schemaMinimum": "3.0.0"
}

Sending same JSON as above I see the same error:

{
    "results": [
        {
            "code": 422,
            "message": "declaration failed",
            "response": "Failed! exit_code (22).\n",
            "host": "localhost",
            "tenant": "Common",
            "runTime": 4202
        },
        {
            "code": 422,
            "message": "declaration failed",
            "response": "Failed! exit_code (22).\n",
            "host": "localhost",
            "tenant": "Common",
            "runTime": 4585
        }
    ]
    }

[dstokesf5]

@megamattzilla Sorry for the confusion. The change was pulled out at the last minute, and it looks like it was not removed from the release notes.

We had to pull the fix since the checking ended up too strict and applying in situations that we did not want it to.

[megamattzilla]

Do you think this will make the 3.37 release?

[dstokesf5]

I believe the fix should be in 3.36.0 as it was only pulled from the 3.35.0 branch.

[dstokesf5]

This issue has been resolved, closing.