Hi again guys,
I am not sure if this is expected behavior for eAPI on v4.1.7M and v4.1.8M.
1. If you web (http or https://10.10.5.165/explorer.html)
2. Issue three commands chained together in the text format:
2a. The first is a valid command of “show ip route”
2b. The second is not a valid command of “show hardware”
2c. The third command is valid of “show inventory”
3. Submit these three commands and you would expect three results back. First result showing you the “ip route” results, the second results saying that the “show hardware” is “Invalid input (at token 1: ‘hardware’)”
4. You only receive the first two results and its seems like when the eAPI processes the second failed command request it stops processing commands all together so in turn does not send the results for the third valid command.
All three commands in this example should be returned
Figure 1. Command Loading of the commands for example above:
Figure 2. Results after the JSON RPC Call to the vEOS switch
Thank you again,
The results you are seeing are by design. eAPI will return an error on the first command that fails and does not process any further commands in the stack.
Peter is right – I also strongly encourage you to check out the CommandAPI Guide, which you can find in the Software Downloads section http://www.arista.com. That should give you more details of how this works and why.
Thank you Andrei! I have read that already, however I don’t recall the verbiage about the error processing. I will certainly go back and read it again. Much appreciated!
Thank you for the confirmation that this behavior is by design. This saves me alot of hair pulling
I would however like to apply for a feature/enhancement to have the switch continue processing chained/stacked commands even if the switch detects an invalid command. The user sends three commands and by nature expects three results (errors or not). If you have a parter exposed feature request form I would be more than happy to attach all information and justification.
Thank you again Peter,
We are now tracking this internally via RFE106371 – we are still investigating this request, so there is no expected release date for this feature as of today.
Post your Answer
You must be logged in to post an answer.