f5-appsvcs-extension
f5-appsvcs-extension copied to clipboard
Dry-run action triggers a "Changes Pending"
Environment
- Application Services Version:
3.13.1
- BIG-IP Version:
BIG-IP 13.1.1.4 Build 0.0.4 Point Release 4
Summary
Sending an AS3 declaration to a BIG-IP in a device group with action
set to dry-run
triggers a "Changes Pending" even if there's "no change". See issue #207.
Steps To Reproduce
Steps to reproduce the behavior:
- Submit the following declaration:
{
"class": "AS3",
"action": "dry-run",
"persist": true,
"declaration": {
"class": "ADC",
"schemaVersion": "3.0.0",
"label": "Sample 01",
"remark": "Simple HTTP application with round robin pool",
"sample01": {
"class": "Tenant",
"defaultRouteDomain": 0,
"Application_1": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": ["10.0.1.11"],
"pool": "web_pool"
},
"web_pool": {
"class": "Pool",
"monitors": ["http"],
"members": [
{
"servicePort": 80,
"serverAddresses": ["10.1.2.101", "10.1.2.102"]
}
]
}
}
}
}
}
-
Sync the devices.
-
Re-submit the declaration.
-
Observe the following response:
{
"message": "no change",
"host": "localhost",
"tenant": "sample01",
"runTime": 557,
"code": 200
}
- Observe the sync status on the BIG-IP:
Changes Pending
Expected Behavior
When the action
is set to dry-run
, sending an AS3 declaration should not trigger a "Changes Pending".
Actual Behavior
A "Changes Pending" is triggered on the BIG-IP, even if the AS3 response message says "no change" and the action
is set to dry-run
.
Thank you for reporting this. I have added it to our internal product backlog as AUTOTOOL-1392.
Any update on this?
There are no updates on this issue at this time.
Is there any update on this?
If you are still looking for a fix, please reach out to us at [email protected]
While investigating this, we determined that it was the updates to the /Common/appsvcs/dataStore data-group and also the creation/deletion of the mutex-lock that are causing a "changes pending" state to happen. These can be skipped with a check for a dry-run, but after some discussion, we decided that it would probably be best to not skip those steps and instead document this behavior as "won't fix" and we will add some notes to the docs to explain why a "changes pending" state is happening in a device group.