Description
This is a change that will break scripts parsing output from gfsh.
Scenario is running with a SNAPSHOT build on a cluster with > 1 server. There is a is a durable-cq on one of the servers, and the gfsh command was
list durable-cqs --durable-client-id=pizza-store
The expected output is
Member | Status | CQ Name -------------------------------------------- | ------ | -------------------------------------------- cacheserver-e3333133-e20e-4f6e-92c3-daaad6.. | ERROR | No client found with client-id : pizza-store cacheserver-2a9d1c06-893b-4e0e-bc6c-546972.. | OK | PestoPizzaOrdersQuery cacheserver-528ca358-3ed2-47b2-a4b6-aa363d.. | ERROR | No client found with client-id : pizza-store cacheserver-b3b91b30-fa3c-4add-97cf-79b2e9.. | ERROR | No client found with client-id : pizza-store
The script fails because it captures the command output and looks for the servers with an OK status. With this SNAPSHOT, gfsh outputs to stderr where earlier versions output to stdout. Note that if this command was run with a --member option with a specific server that has the durable-cq, then the output DOES go to stdout.
Bottom line for scripting with gfsh: It's no longer predictable where to look for output, stderr or stdout.
As a side note: From a user point of view, indicating an ERROR status for members on a command like this is misleading. The non-existence of a durable-cq on member 'xxxxx' is a statement of fact and not necessarily an error. Reprorting N/A or DOES NOT EXIST would be more appropriate
Attachments
Issue Links
- links to