Date: Fri, 29 Mar 2024 07:22:07 +0000 (UTC)
Message-ID: <120713196.35467.1711696927607@aws-us-west-2-lfedge-confluence-1.web.codeaurora.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_35466_1273269778.1711696927606"
------=_Part_35466_1273269778.1711696927606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Motivation
Document here describes new debug enhancem=
ents required in EVE. At a high level, we need the ability to request any E=
VE running node to perform certain
operations (eg: get output of a command, do clear operation on a given d=
irectory) and return the output/status of execution back to Zedcloud. =
Such ability in EVE
can be helpful when debugging EVE nodes in problem state and also for au=
tomation scripts to get status from devices without a direct SSH connection=
.
The document linked above describes at a high level the mechanism for se=
nding such commands to device and lists a set of useful debug commands. It =
is still
not very clear how the result of command execution should be sent back t=
o Zedcloud. Output sent from EVE node should be in a form useful for both l=
ogging and
be convenient for processing with other software (eg: cloud code for sto=
ring in DB or integration tests for checking status/counters).
EVE res=
ponse to Zedcloud
Two possible ways of sending command response back to zedcloud:
- Split command output into multiple lines (carriage return delimited spl=
it) and log each line similar to any other log. Command id (random number t=
hat user sends
along with the command) will be logged as part of each line. These logs wil=
l reach Kibana using the exiting logging mechanism.
Pros:
- Relatively easy to implement.
- Loss of data due to buffer size limitations (per line logged) is hi=
ghly unlikely.
Cons:
- Since the response not stored as object in cloud, it cannot be quer=
ied & retrieved.
- Difficult to interpret for both human users and software.
- No possibility of time series data analysis if required later.
- Create a new API endpoint and new proto message for sending command out=
put response to Zedcloud.
message CommandResponse {
CommandId int; =
// Random/running number coming from user
FirstFrag &nb=
sp; bool;
MoreFrag &nbs=
p; bool;
FragData &nbs=
p; string;
}
Depending on the output size from command and the data size imposed by API,=
multiple messages can be created in EVE and sent to Zedcloud.
Zedcloud would only store the last unfragmented/fully re-assembled command =
response.
EVE not makes sure that it does not interleaves messages corresponding to d=
ifferent commands at the same time.
Pros:
- Easy to consume for both human users and software. Easy to query for last=
response from cloud.
- Integration tests can query for specific command outputs without needing =
direct SSH connection to EVE node.
Cons:
- Takes relatively more effort on the EVE side.
- Zedcloud will need software changes to support this.
Please comment if there are other ways of doing this and any suggestions=
to the methods above.
------=_Part_35466_1273269778.1711696927606--