Open samualblair opened 2 years ago
Adding @rjouhann for BIG-IQ visibility
Sure, I wasn't sure if this was expected or not in some cases.
I have opened up SR# C3809702
Curious if there was any change or plan regarding this. I was told in SR# C3809702 that: " Product Development has tracked down an issue where BIG-IQ can read the first task response, but has difficulty when multiple tasks are executed - it gets the success from the first, but not the failure from the second task.
They have filed bug ID1127929. "
I have not seen that ID publicly published, so I assume this is either some solution in the works or has been put on hold for now.
Is your feature request related to a problem? Please describe.
BIG-IQ reports declaration/deploy success even when a config load failure occurs on BIG-IP. This appears to occur when the Declaration is valid from an abstract point of view, and therefore schema checks are passed. When the BIG-IQ then sends configuration to the BIG-IP but the BIG-IP fails to load specific components the push effectively fails.
Just some possible local BIG-IP failure examples: New declaration has an iRule that calls upon a datagroup that is not present. New declaration requires a removal of a node before a new node in a different route domain can be added.
In the BIG-IQ WebGUI and/or AS3 API the declaration reports as successful.
Yet the result is a failure, or at least partial failure. In the CLI logs, primarily on BIG-IP "/var/log/restnoded/restnoded.log" the specific failure can be seen. The failure can also be seen on BIG-IQ log files such as "/var/log/restjavad.0.log" the specific failure can be seen.
Ideally the API status of an AS3 deployment would be success or failure based on actual result.
Describe the solution you'd like
I would like the BIG-IQ to show an AS3 declaration failure instead of reporting success when failure occurs loading configurations.
Describe alternatives you've considered
I do not know of any alternative, other than monitoring log files at all times (which is not tenable or easily programmable). Perhaps this is a BIG-IQ limitation more than an AS3 limitation? I have considered that perhaps this is the current situation because the 'AS3' part is successful even though the actual configs on BIG-IP are not (due to failure with standard rest API , or local failure that is not easily reported on).
Additional context
In this scenario all API calls are AS3 to/from BIG-IQ. BIG-IQ then translates and manages BIG-IP configurations.