F5Networks / f5-appsvcs-extension

F5 BIG-IP Application Services 3 Extension
Apache License 2.0
169 stars 54 forks source link

AS3 declaration results in errors when binding an HTTP irule on a Virtual Server with no HTTP profile set, dryrun exits with no errors #883

Closed seamlessfirework closed 1 week ago

seamlessfirework commented 1 month ago

Environment

Summary

I have an AS3 tenant declaration. The Virtual Servers are being deployed as TCP loadbalancers with class "Service_TCP" with a "security-fastL4" profile. I accidently added an iRule that needs an HTTP profile set. The declaration failed properly saying that the VS needs an HTTP or FastHTTP profile being set.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Submit the following declaration:
    {
    "$schema": "https://raw.githubusercontent.com/F5Networks/f5-appsvcs-extension/main/schema/latest/as3-schema.json",
    "class": "AS3",
    "action": "deploy",
    "persist": true,
    "declaration": {
        "class": "ADC",
        "schemaVersion": "3.53.0",
        "mytenant": {
            "class": "Tenant",
            "vs_name": {
                "class": "Application",
                "template": "generic",
                "vs_name": {
                    "class": "Service_TCP",
                    "remark": "fqdn",
                    "virtualAddresses": [
                        "1.2.3.4"
                    ],
                    "virtualPort": 1234,
                    "redirect80": false,
                    "snat": "auto",
                    "profileL4": {
                        "bigip": "/Common/security-fastL4"
                    },
                    "allowVlans": [
                        {
                        "bigip": "/Common/interface"
                        }
                    ],
                    "pool": {
                        "use": "pool_name"
                    },
                    "persistenceMethods": [
                        "destination-address"
                    ],
                    "iRules": [
                        {
                    "bigip": "/Common/my_irule"
                    }
                    ]
                },
                "pool_name": {
                    "class": "Pool",
                    "loadBalancingMode": "round-robin",
                    "monitors": [
                    {
                        "use": "my_monitor"
                    }
                    ],
                    "minimumMonitors": 1,
                    "members": [
                        {
                            "shareNodes": true,
                            "remark": "node",
                            "servicePort": 1234,
                            "serverAddresses": [
                            "4.3.2.1"
                            ]
                        }
                    ]
                }
            }
        }
    }
    }
when HTTP_REQUEST priority 100 {
    # Remove untrusted HTTP X-Forwarded headers
    # from HTTP requests and set our own:
    #
    # - X-Forwarded-For
    # - X-Forwarded-Host
    # - X-Forwarded-Port
    # - X-Forwarded-Proto
    # - X-Real-IP
    #
    #  X-Forwarded headers clean-up
    #
    HTTP::header remove X-Forwarded-For
    HTTP::header remove X-Forwarded-Host
    HTTP::header remove X-Forwarded-Port
    HTTP::header remove X-Forwarded-Proto
}
  1. Observe the following error response:
    Posting declaration
    Waiting for task id "00893406-304e-476f-a487-6f561dbdfdbb" to finish.
    ERROR: AS3 declaration failed: 422
    [
    {
    "code": 422,
    "message": "declaration failed",
    "response": "01071912:3: HTTP_REQUEST event in rule (/Common/my_irule) requires an associated HTTP or FASTHTTP profile on the virtual-server (/mytenant/vs_name).",
    "host": "localhost",
    "tenant": "mytenant",
    "runTime": 1645,
    "declarationId": "autogen_ee1a6e2c-f71b-4698-ae63-5fbeb958caf8"
    }
    ]

Expected Behavior

I expected that in the dry run a error message says that the VS needs a proper profile when binding an iRule that is being used for HTTP packet handling.

Actual Behavior

The dry run didn't report any errors:

Dry-run enabled
Posting declaration
Waiting for task id "f00f2179-8165-4afd-ab08-c35273c7a1bd" to finish.
mdditt2000 commented 1 month ago

please can you open a Service Request for this issue. Thank you Mark

seamlessfirework commented 2 weeks ago

This is the response I got from the support team:

in this specific case we don't expect complains from AS3. Dry-run checks if AS3 declaration is syntactically correct the error you are facing is from mcpd which checks if the config is valid. ( we cannot have irule without http profile) So in other words is expected not to see complains from dry-run.

I replied this

I would expect that the dry-run throws errors when an HTTP profile is needed when binding an iRule with "when HTTP_REQUEST..." and so on. So what does the dry-run really do? IMHO I cannot rely on the dry-run feature behaving like that.

I got this answer

The error that you are facing is from mcpd which checks if the config is valid. A dry run is an action that sends a declaration through validation checks without deploying the configuration to the target device. It's useful for debugging and testing declarations. In other words, dry-run checking the declaration, not the configuration for configurations mismatches mcpd is used.

I have to keep this in mind and rethink a bit about the behavior of the dry-run feature. What do you think about the response from support team?

ZdenekZemba2 commented 1 week ago

I am not big fan of AS3 and the whole stuff around Next/CM but in this case the response from support team is IMHO valid. We do automate imperatively and had the same challenge as you and it might be tricky to pre-verify irule content against virtual server configuration. It is not only about http profile vs "when HTTP_REQUEST" but you have much more types (stateless, L4, ..) which support or not support various types of iRule events. Simply, I would say this outcome is fine.

seamlessfirework commented 1 week ago

Thank you for your input. I would say this problem has been “solved”.