Health check command - standard is not clear

[kalsky]

The standard doesn't mention if the command should be hidden or not, but in the shell templates it does appear as hidden.

If it's an hidden command, that should be called by the orchestration/api, then it needs to be more flexible and "machine" oriented.
That means:

1. get an input if the live status should be changed (i think it's not the shell's decision anyway, and that shells should not use the api in most of the times - but that's something else). The orchestration should be able to decide which live status to set on the resource.
2. return an output that is easy to parse like 1/0 and not a string that changes by the resource name.

We can go to an approach of having both options - an "orchestration_health_check" function which is hidden, and a user facing function like the current one that just calls the orchestration one and adds the live+output as needed.

The brocade and ericsson implementation doesn't hide this command - so after deciding if it should be hidden - a bug should be opened to either the templates or ericsson+brocade drivers.

[doppleware]

The command is intended as orchestration only. You can include other commands that perform similar functions to be called by users (probably will delegate to the same code).
Right now it is the Shell's decision about the status, as it can't work with that resource if healthcheck fails.
You are right about the output, it should conform to a JSON schema that will make it easier to parse.
Thanks,
Roni

[kalsky]

what do you mean by "Right now it is the Shell's decision about the status, as it can't work with that resource if healthcheck fails."?
I don't think a shell (or orchestration) should read the live status to make sure it can access the device (if that's why they are setting the status on the resource for).
If it's a shared resource, other commands might change the live status for other values in other reservations..
And in other cases, you'll want to report progress or show a different status after the orchestration is done.

Anyway, that's why i'm saying that if this is a hidden command, we can let the orchestration decide about setting the live status (via input), same as (kind of) it decides to print the result to the commands output.

[alonagetzler]

This isn't a hidden command, and it should set the live status. I'll clarify that in the standard. We will consider adding an orchestration_healthcheck command that will return a JSON output.