f5-appsvcs-extension
f5-appsvcs-extension copied to clipboard
F5Networks
Cant rename virtual server. Experiencing code 422 Declaration failed
Environment
- Application Services Version: 3.45.0
- BIG-IP Version: 15.1.x
Summary
After a virtual server is declared, simply changing the virtual server name evokes a 422 declaration failure error.
Steps To Reproduce
Steps to reproduce the behavior:
- Submit the following declaration:
{
"class": "AS3",
"action": "deploy",
"persist": true,
"declaration": {
"class": "ADC",
"schemaVersion": "3.13.0",
"id": "123abc",
"label": "Sample 1",
"remark": "An HTTPS sample application",
"controls": {
"trace": true
},
"Common": {
"class": "Tenant",
"Shared": {
"class": "Application",
"template": "shared",
"demo-http": {
"class": "Service_HTTP",
"virtualPort": 9999,
"redirect80": false,
"virtualAddresses": [
"10.5.20.245"
]
}
}
}
}
}
- Declaration successful.
- Submit the following declaration:
{
"class": "AS3",
"action": "deploy",
"persist": true,
"declaration": {
"class": "ADC",
"schemaVersion": "3.13.0",
"id": "123abc",
"label": "Sample 1",
"remark": "An HTTPS sample application",
"controls": {
"trace": true
},
"Common": {
"class": "Tenant",
"Shared": {
"class": "Application",
"template": "shared",
"demo-http2": {
"class": "Service_HTTP",
"virtualPort": 9999,
"redirect80": false,
"virtualAddresses": [
"10.5.20.245"
]
}
}
}
}
}
- Observe the error message
"results": [
{
"code": 422,
"message": "declaration failed",
"response": "01070333:3: Virtual Server /Common/Shared/demo-htt2 illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /Common/Shared/demo-http.",
"host": "localhost",
"tenant": "Common",
"runTime": 12942
},
Expected Behavior
Declaration is successful with no error messages. Virtual server is renamed in Big-IP configuration.
Actual Behavior
Error message is observed. Strangely, the virtual server name is updated in the Big-IP configuration despite the AS3 error message. If you re-run the exact same declaration (with name change) twice then it will complete successfully the second time with no error message.
AS3 processes Common/Shared in 2 passes. The first pass adds new objects in Common/Shared and the second pass deletes objects that are no longer needed in Common/Shared.
https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/userguide/best-practices.html#keep-the-number-of-applications-in-one-tenant-to-a-minimum
Just letting you know that I suspect what you saw looked liked this --
"results": [
{
"code": 422,
"message": "declaration failed",
"response": "01070333:3: Virtual Server /Common/Shared/demo-http illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /Common/Shared/demo-http2.",
"host": "localhost",
"tenant": "Common",
"runTime": 4461
},
{
"code": 200,
"message": "success",
"lineCount": 18,
"host": "localhost",
"tenant": "Common",
"runTime": 3903
}
]
Since two virtual servers cannot share those properties shown in that BIGIP error message the first pass failed to add the new server but in the second pass the old virtual server was deleted. The second pass also saw the new virtual server still had not been created yet and lumped it into the same transaction with the delete making it work in the second pass despite the error message from the first pass.
You can confirm this by seeing a second POST has "no change" in the results for both passes.
"results": [
{
"code": 200,
"message": "no change",
"host": "localhost",
"tenant": "Common",
"runTime": 3246
},
{
"code": 200,
"message": "no change",
"host": "localhost",
"tenant": "Common",
"runTime": 3188
}
]
I confirmed my results look like what Rob mentioned:
"results": [
{
"code": 422,
"message": "declaration failed",
"response": "01070333:3: Virtual Server /Common/Shared/demo-http2 illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /Common/Shared/demo-http.",
"host": "localhost",
"tenant": "Common",
"runTime": 11116
},
{
"code": 200,
"message": "success",
"lineCount": 18,
"host": "localhost",
"tenant": "Common",
"runTime": 11185
}
],
The I think the error handling needs to be improved when you rename a virtual server in this manner.
When you check to see if AS3 declaration task was successful, observing 422 declaration failed usually means a blocking error and that the configuration was rolled back to last successful.
That led us to believe this was a blocking error and that the change should not have been performed.
Its going to be difficult to program our automation that checks for AS3 task failures that 422 declaration failed reason xyz is not a real failure.
When you legitimately have overlapping VS servers, the resulting error response contains the same text and differentiating between a real or cosmetic error at that point is difficult.
Is there a way to suppress or mask this cosmetic failure response code? Maybe not a 422?
I see the same behaviour when moving a Virtual Server to another tenant.
When attempting to move from tenant inf to cm10 I receive the below, but running the declaration succeeds the second time.
Presumably the cm10 tenant is just being implemented before inf.
Not really a big issue for me as it's a fairly rare to do, but would the fix be to have the previous partition (or partition being removed) listed first in the declaration? Or given they're arbitrarily named keys, not within an array, is the iteration of tenants within a declaration not guaranteed to retain the order of definition?
run1:
[
{
"code": 422,
"message": "declaration failed",
"response": "0107176c:3: Invalid Virtual Address, the IP address 10.253.1.14 already exists.",
"host": "localhost",
"tenant": "cm10",
"runTime": 3097
},
{
"code": 200,
"message": "success",
"lineCount": 33,
"host": "localhost",
"tenant": "inf",
"runTime": 3533
}
]
run2:
[
{
"code": 200,
"message": "success",
"lineCount": 35,
"host": "localhost",
"tenant": "cm10",
"runTime": 3073
},
{
"code": 200,
"message": "no change",
"host": "localhost",
"tenant": "inf",
"runTime": 926
}
]
Thank you for reaching out. We have created a internal product backlog for this item, in order for us to prioritize please reach out to us at [email protected]
