nasa-ammos / anms Goto Github PK

Several ADMs displayed in the Adms tab were selected for comparison of the Build tab entries and the IETF definition. Comparisons of controls, tables, and reports were made. It was noted that for the bpsec and ltp agent ADMs 'list' controls were given in the ADM but were not provided in the Build tab. The correct versions of the ADM were compared.

It would be helpful to highlight the page number selected when more than one page is displayed in the log, especially when the '>' or '<' options are used.

The test steps to add an ARI with parameters did not generate the expected result in the transcoder log display. Discussions with the developer revealed the new submission was a duplicate of an existing entry, and as such, will not be retranslated.

It is suggested a message be displayed to the user indicating this, with the message providing the transcoder log ID of the existing entry. The user guide should also cite this as an expected behavior.

It has been noted that entries in the Build tab "String Input" field are submitted without selecting the SUBMIT button. Selecting the "ARI Builder" option or selecting another tab will submit the abandoned "String Input" entry.

Entries for the ARI Builder have been started in this string field when neglecting to select the ARI Builder option. The extraneous characters are displayed in the transcoder log and an attempt to convert the string is made, adding to the processing time for converting input.

A command to generate a table of the rules known to an agent (amp agent ADM) was generated and executed, but no rules were displayed.

When a state-based rule was created to generate the same rules table, the table was populated.

The state-based rule was:
ari:/IANA:amp_agent/CTRL.add_sbr(ari://Sbr.SBR15,0,(UINT)[ari:/IANA:amp_agent/EDD.cur_time],10,5,[ari:/IANA:amp_agent/CTRL.gen_rpts([ari:/IANA:amp_agent/RPTT.full_report],[]),ari:/IANA:amp_agent/CTRL.gen_tbls([ari:/IANA:amp_agent/TBLT.rules],[])],"SBR15")

The rule ID, 0x08455342523135, listed while the state-based rule was running, was submitted in the Build tab and it was transcoded to the expected state-based rule name, "ari:/SBR.SBR15".

The command to generate a table of the rules known to the agent was re-run and was not populated. The description for the rules table template (amp agent) indicates it lists the rules known to the agent, it does not state it lists the rules currently running.

The ADM description should be changed or the agent behavior should match the ADM.

The Message Groups per Minute and ARIs panels should have an 'information' option providing the purpose of the panel, to be consistent with the Number in Custody and Received Reports panels.

It was noted that executing the conversion of valid CBOR strings frequently does not generate results in Build tab transcoder log. Discussions with the developer indicate duplicate entries are rejected, but the user is not informed of this. The user guide should mention this behavior and it would be helpful for the Build tab to display a message when a duplicate entry is found.

When the ANMS sends to ION a hex sequence that contains a blank space, e.g. 0xc11541050502252381871819410000 (space at the end) the result is a log message from docker exec ion-manager journalctl --unit ion-nm-mgr --since today similar to:

Mar 17 14:42:27 ion-manager nm_mgr[77]: [nm/shared/utils/utils.c:193] x utils_atox x Non-hex character:
Mar 17 14:42:27 ion-manager nm_mgr[77]: [nm/shared/utils/utils.c:407] x utils_string_to_hex Can't AtoX 0 .

An APL IRAD project separated the AMP Agent and Manager from the ION source tree, with shim behavior to retain existing ION application behavior.

The project is hosted on Github at DTNMA-Tools and could be added to or forked into the ANMS to enable tracking AMP/ADM document updates. Those document updates haven't fully stabilized, so this is a future enhancement ticket.

It was noted several EDDs listed for selection in the Build tab Select ARI field have a type of (REF:xx), where xx is a number. Another instance of this EDD also exists, but has the expected data type (e.g., STR). Selecting an EDD with the REF creates an error when the control is submitted.

It would seem the EDDs with REF should be removed from the selection list.

Test case executed as expected.

It was noted that repeated modifications to an existing ADM were not always reflected in the ADM table, that is, no message indicating a successful upload was displayed. No error messages were displayed, but the exported ADM did not include the expected modifications.

It seemed necessary to remove the ADM and upload it again to get the desired modifications.

When a table of reports known to an agent is generated, the table lists the ARIs of the reports, several of which have the same ID. For example:
[
{
"eid": "ipn:1.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "rptts",
"timestamp": "Fri Jun 30 19:33:23 2023\n",
"entries": [],
"type": "tblt",
"table": {
"cols": [
{
"name": "ids",
"type": "ARI"
}
],
"rows": [
[
"endpointReport((UINT ltp_span))"
],
[
"full_report"
],
[
"full_report"
],
[
"source_report((STR Source))"
],
[
"endpoint_report((STR endpoint_id))"
],
[
"full_report"
]
]
}
}
]

There is no indication of the ADM, namespace, or other means of identifying what 'full report' is known. The table template should be modified.

The Build tab was used to successfully build and execute a control to describe a rule.

The description of this control, from the amp-agent ADM is:
{
"name": "desc_rule",
"parmspec": [{
"type": "AC",
"name": "ids"
}],
"description": "This control produces a detailed description
of one or more rules known to the Agent."
}

The actual report generated was:
{
"eid": "ipn:1.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "desc_rule",
"arguments": "Anonymous ARI: 0x0b487465737454425231 ",
"timestamp": "Mon Aug 14 17:55:57 2023\n",
"entries": [],
"type": "unknown"
}
]
}
]

It is not clear what details are provided.

The test was successfully executed, but it was noted guidance is needed when specifying the order of stopping services. For example, the Transcoder service was successfully stopped and the Status tab showed that service as stopped, and the remaining services as running. The nginx service was stopped next and the Status page no longer displayed any services, but did show an AxiosError with an error code of 503. The test steps to restore the services did not successfully restore them. The hierarchy of services need to be considered for this test. The test specification was updated to reflect this and perhaps some guidance should be provided in the user manual.

The gen_rpts control was selected, on the Build tab, to generate a source report. The label for the input parameter was "last_reset(STR)". The bpsec ADM seems to indicate the parameter is "Source" ("parmspec": [{"type":"STR","name":"Source"}],) . The last_reset is part of the source report defined as:
{
"ns":"DTN/bpsec",
"nm": "Edd.last_reset",
"ap": [{
"type": "ParmName",
"value": "Source"
}

The EDD definition is:
"name": "last_reset",
"type": "TV",
"parmspec": [{"type":"STR","name":"Src"}],
"description": "Last reset"
}

It is not clear what the input should be.

A new ADM was created, based on the amp-agent ADM, successfully uploaded and downloaded. However, it was noted that an operation:
"name": "STOR",
"result-type": "UNK",
"in-type": ["UNK", "UNK"],
"description": "Store value of parm 2 in parm 1"
was not included in the possible Aris in the Build tab. It was also noted this operation was not listed for amp-agent elements in the Build tab.

When the user profile was first created and when redisplayed for updates, no 'Cancel' option was provided. Selecting another tab in the GUI closed the profile.

When the profile was selected again, no data was displayed for the Email, First and Last Names. It was necessary to logout and in again to see the profile data.

The option to display user information has Profile and Administration tabs. There is no change in the display when either is selected.

When supplying the parameters for a time-based rule through the Agents tab, it was noted that invalid entries (character and negative values) for the Start and Period fields did not generate error messages when the time-based rule was submitted. The problem was noted when no reports where generated for the rule.

All the numeric fields for the time-based rule option have a 'selector' to scroll through positive and negative values for the fields. If negative values are invalid, these selectors should not allow that range.

Time-base rules were being executed as on option of the Agents Manage agent. After submitting several rules to ipn:2.6 and ipn:3.6, the nodes were not recognized as given in the following message: error sending request to node! (check node index) Request failed with status code 502.

After an input string is generated and displayed in the Build tab transcoder log, it would be useful to be able to edit that string, either to correct errors or to modify parameters. Directly editing the string in the log or having the string redisplayed in the input fields for edit would be convenient.

ANMS_EXP_AGT_001 (Agents)
No results were displayed when a complete registered date, for example 2023-01-27T18:30:04.663900, was copied from the agent table and pasted as a filter. Subsequent filters based on complete and partial portions of the date and time were successful.

It would seem filters with alpha characters are applied only to the agent id attribute.

It would be useful to see the header row of the tables displayed on the Monitor tab when scrolling through the tables.

v0.3.0-66-g6ff87b8

The Build tab was used to create the following
⦁ a table of keys
⦁ ari:/IANA:amp_agent/CTRL.gen_tbls([ari:/IANA:bpsec/TBLT.keys],[])
⦁ 0xC115410605022523818A18CF410000
⦁ a report with various counts, including the number of known keys

The number of known keys was displayed in the count report as "last_update". Another report was generated with the number of known keys and the key names.
⦁ ari:/IANA:amp_agent/CTRL.gen_rpts([ari:/IANA:bpsec/EDD.num_known_keys,ari:/IANA:bpsec/EDD.key_names],[])
⦁ 0xC1154105050225238682164108821641038216410582164100821641098218CA42181900

This report had an entry of known keys, but the key names were displayed as "last_update". The report follows:
[
{
"eid": "ipn:1.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "last_update",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
},
{
"num_entries": 1,
"recipient_name": "",
"name": "num_known_keys",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
}
]
},
{
"eid": "ipn:2.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "last_update",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
},
{
"num_entries": 1,
"recipient_name": "",
"name": "num_known_keys",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
}
]
},
{
"eid": "ipn:3.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "last_update",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
},
{
"num_entries": 1,
"recipient_name": "",
"name": "num_known_keys",
"timestamp": "Thu Jul 6 16:24:00 2023\n",
"entries": [
0
],
"type": "unknown"
}
]
}
]

the nm is adding actual report template into the control_actual_definition table when getting reports from agents. Shouldnt be creating report templates and should definitely not be adding them to the control table. currently removed actual control view from ARI_union

Allow for an administrative REST API and supporting logic for responding to service failures with cascading fallback strategies (e.g. logging to files while OpenSearch is disconnected and recovering), as well as updating service connections based on configuration updates. When changes are made or fallbacks are applied this should be a cause for notifications and logging, so that administrators understand when an issue has occurred and if there is anything that is needed in response.

server
"name": "tough-cookie",
"severity": "moderate",
"name": "request",
"severity": "moderate",

public
flat critical
jsdom moderate
tough severity
ejs critical
loader severity
json5 high
tough severity
tough severity
minimatch high
request moderate

It was noted that when multiple alerts are displayed, the page may be refreshed, removing the current alerts to display new alerts. This refresh sometimes occurs before the user has the opportunity to review all the alerts currently displayed.

An option to review past alerts would be useful.

The Build tab was used to create a CTRL.gen_tbls and to specify various table templates. The resulting raw command was run and the results were displayed with the Agents tab ‘Print Agents Reports’. The report displayed had a header of ‘reports’, followed by entries for each selected table template. The columns were provided and the data for the columns, when applicable. The template and structure for each ‘tblt’ matches the ADM.

When
ari:/IANA:amp_agent/CTRL.gen_tbls([ari:/IANA:amp_agent/TBLT.rptts(),ari:/IANA:amp_agent/TBLT.rules()],[])
is executed, the result is, identified with “reports” not tables? (See below.)

There is an Agent option to ‘Clear Agent Tables’ and this was executed, assuming what the display contained tables. A message indicating “error sending request to node! (check node index) Request failed with status code 404.”

The ‘Clear Agent Reports’ option was selected and the display was cleared.

The question is, what is a table?

If this is some future option, perhaps it should not be available for selection, following the ‘Write Agent Reports to file’ option, which displayed, but cannot be selected.

{
"eid": "ipn:3.6",
"reports": [
{
"num_entries": 1,
"recipient_name": "",
"name": "rptts",
"timestamp": "Fri Jan 6 18:45:04 2023\n",
"entries": [],
"type": "tblt",
"table": {
"cols": [
{
"name": "ids",
"type": "ARI"
}
],
"rows": [
[
"endpointReport((UINT ltp_span))"
],
[
"full_report"
],
[
"full_report"
],
[
"source_report((STR Source))"
],
[
"endpoint_report((STR endpoint_id))"
],
[
"full_report"
]
]
}
},
{
"num_entries": 1,
"recipient_name": "",
"name": "rules",
"timestamp": "Fri Jan 6 18:45:04 2023\n",
"entries": [],
"type": "tblt",
"table": {
"cols": [
{
"name": "ids",
"type": "ARI"
}
],
"rows": [
[
"Anonymous ARI: 0x8b014104"
],
[
"Anonymous ARI: 0x8b014105"
],
[
"Anonymous ARI: 0x8b014106"
]
]
}
}
]
}

Based on the generated results for rptts, I can create:

ids
endpointReport((UINT ltp_span))
full_report
full_report
source_report((STR Source))
endpoint_report((STR endpoint_id))
full_report

Having three entries for full_report without additional information is not as useful as it might be.

Additional Notes

If CTRL.gen_rpts must be used to create reports, its parameters must include report entities and not table entities.

When
ari:/IANA:amp_agent/CTRL.gen_rpts([ari:/IANA:amp_agent/TBLT.rptts(),ari:/IANA:amp_agent/TBLT.rules()],[])

is executed, the result is:
{
"eid": "ipn:3.6",
"reports": [
{
"num_entries": 0,
"recipient_name": "",
"name": "rptts",
"timestamp": "Fri Jan 6 18:31:53 2023\n",
"entries": [],
"type": "tblt"
},
{
"num_entries": 0,
"recipient_name": "",
"name": "rules",
"timestamp": "Fri Jan 6 18:31:53 2023\n",
"entries": [],
"type": "tblt"
}
]
}

The same appears to be true for CTRL.gen_tbls, parameters are table related not report related
When
ari:/IANA:amp_agent/CTRL.gen_tbls([ari:/IANA:amp_agent/RPTT.full_report()],[])
is executed, generates:

{
"eid": "ipn:3.6",
"reports": []
}

It was noted the same alerts seem to be redisplayed, after being cleared. No additional agent modifications were made, but the same alerts redisplayed, and sometimes with different alert IDs.

dedicated expression and macro builders enhanced modularity

The necessity of changing the number of items/page for the Transcoder Log to display the latest submission should be removed.

It was noted the IDs for alerts were re-used for different messages. Sometimes the same ID had the same message, or a related message. For example:

• ALERT 22: ipn:1.6 removed
• ALERT 22: ipn:1.6 added

Other IDs had different messages:
ALER- T 13: ipn:3.6 removed (orange background)

• ALERT 13: failed to reach manager (red background)
• ALERT 9: ipn:2.6 removed (blue background)
• ALERT 9: reconnected to manager (blue background)

It is assumed the alert colors indicate the severity and that the user guide will discuss this.

Additional IDs and messages follow:
29 1.6 added
30 2.6 added
31 3.6 added
32 4.6 added
33 Failed to reach manager
34 1.6 removed / 3.6 removed
35 3.6 removed / 1.6 removed
36 2.6 removed / 3.6 removed
37 1.6 removed / 4.6 removed
38 2.6 removed
39 1.6 removed / reconnected manager
40 2.6 removed
41 Reconnected to manager

Alert_IDs.docx

An invalid agent address was specified for the Manage agent option on the Agents tab. A time-based rule was specified and submitted. It was expected an error message would be generated, but it was not. An error message was not generated until the option to Print Reports for the invalid agent was selected.

The amount of time required to process a submission needs to be reduced.

The Agents tab option to "Clear Agent Tables" has not yet been implemented, but it is available for selection. Suggest this option be greyed out as is the "Write Agent Reports" to file option.

The test case instructs the tester to create a time-based rule generating an amp agent full report every second until 120 reports are reached.

The test case instructs the tester to verify all the reports were generated. The Print Reports option from the Manage Agents did not include the expected number of reports. The first report displayed had a timestamp of 18:26:15. The last report displayed had a timestamp of 18:27:54.

It was expected for:
⦁ Minute 19:42:20 there would be 40 messages
⦁ Minute 19:43 there would be 60 messages
⦁ Minute 19:44 there would be 20 messages, with the last report generated about 19:44:19

The timestamp on the last report displayed was 19:43:59.

The Message Groups/Minute display corresponded to the expected message distribution. The Reports Received displayed listed the last report time as 15:43:59 (assuming the difference in hours displayed to be related to time zones).

The database table vw_rpt_entries has 100 rows for the time-based rule.

It would appear there is a limit (about 99-100) to the number of reports displayed on the Agents page and the Reports Received. It may be acceptable to limit the number of reports displayed on the Agents page (user guide should discuss this), but one would expect all the reports to be listed in the Received Reports panel.

Along with other issues that will allow the transcoder to perform transformations/encodings between protocols, there should be a registration process that the anms-core supports for translation services to indicate which combinations of protocols (pair-wise) can be translated between. It should be directional, in case transformations are asymmetric. Also, the service should only rely on the latest registration information and not based on persisted information, as this might make the ability to inform users hard coded or less dynamic.

• Figure out where things will break once we start to add dozens, hundreds of agents, and how we can build in scalability early. - writing tons of different things to different tables at the same time -- should we break up postgres instances?

It was noted that alerts are displayed with different 'colors', assumed to indicate a severity level.

An option to select the level of alerts displayed would be useful.

An option to clear all alerts displayed rather than selecting each one for removal would also be useful.

It would also be useful to have an option to turn off the display of alerts. Perhaps have an icon indicating there are alerts available for review? Selecting that icon would then display the alerts.

An existing transcoder log ID was used to filter the log, with the number of items per page set to 10. The items displayed did not show the selected ID, which was not within the range of IDs displayed, and selecting the navigation options to display previous or next pages did not display new pages. See existing Issues 197 and 200 for additional comments.

The current work flow for creating commands in the Build tab and executing them in the Agents tab works successfully.

When series of commands are to be executed, the flow is:

1. Create the command in the Build tab
2. Wait for the command to appear in the transcoder log
3. Select the command in the transcoder log to display the Agents tab
4. Enter the agent ID(s) on the Agents tab
5. Select Manage Agents option
6. Select the Send Raw Command option, which has the new command populated
7. Select Manage Agents option again
8. Select Print Agents Report option
9. Repeat from 1 for the next command

This requires frequent switching between the Build and Agents tab.

Alternately, all the commands could be created at once in the Build tab. In this case, once the commands are created, the flow would start at step 3 above and be repeated from there for each command. But the same amount of switching is still needed.

The Cbor string could be copied from the Transcoder log for each command to be executed and stored somewhere. The flow in this case would be to display the Agents tab, enter the Agent(s), and proceed from step 5 above, pasting the command to be executed in the Raw Command field (step 6). Executing additional commands would proceed from step 6. This option requires less switching between the Build and Agent tabs, but it sometimes requires some effort to copy the command in the transcoder log without bringing up the Agents tab, which is the expected behavior, but is not always wanted. The user is also responsible for pasting the correct string in the correct sequence.

Developing a macro could be developed to contain all the steps wanted, but a macro may not always be wanted and it brings its own set of additional steps to be executed.

Could multiple commands be selected from the transcoder log? Perhaps with a column to enter an execution sequence number for each command? Or display the transcoder log IDs on the Agents tab and let the user select the command to execute. The user would be expected to know what commands the IDs represent. The user would like to reduce the number of switches between tabs and the re-entering of the agent IDs.

explore bootstrap options to make UI have better accessibility

Is there a way to add a 'delete' or 'cancel' option to a pending submission on the Build tab? A 'Cancel' option would be really useful for a pending string, particularly when one notices an error.

When a filter string is defined for the Select ARI field on the Build tab, it would be nice if the filter were retained, rather than having to redefine it after a selection.

For example, if the filter "amp_agent/EDD" is set, a list of ARIs are displayed for selection. Once a selection is made, the filter string is removed and has to be defined again.

Not intuitively obvious columns may be sorted, arrow displayed after column heading selected.
⦁ Not sure column is being sorted. Selected the Report ID, the first ID was 1, and it went to '1' with an up arrow, expected to see the last report ID. Selected the column again and got a down arrow with ‘124’. Selected the column heading again, and ‘1’ was the first row displayed. Appears to be a 'feature' of Grafana.
⦁ Similar behavior was noted when the remaining columns were sorted. It appeared the data would be sorted in ascending, then descending order, and an attempt to return to ascending order displayed unexpected order.
⦁ A sort is executed when columns without data are selected, it would appear the Report ID is used.

Correct spelling of title (Recieved Reports)

A time-based rule was created to generate bp full reports 1/second for 180 counts.

Agent 1.6 was selected to run this TBR starting at time 42:30. It was expected:
⦁ For minute 42: 30 messages would be generated
⦁ For minute 43: 60 messages would be generated
⦁ For minute 44: 60 messages would be generated
⦁ For minute 45: 30 messages would be generated

At time 43:33, the TBR was submitted for agent 2.6 and the same message distribution was expected.
At time 44:30, the TBR was submitted for agent 3.6 and the same message distribution was expected.

The Message Groups per Minute displayed reflected the expected distributions until 44:44. No additional points were displayed for agents after that time, the messages for minute 44 were as expected:
⦁ 45 for agent 1.6,
⦁ 44 for agent 2.6
⦁ 13 for agent 3.6

The Received Reports panel also stopped at this time. It is a known problem with the Received Reports panel that not all reports will be displayed, generally stopping at about 98-99 reports.

At this point, no other commands could be submitted for the agents without receiving an index error.

An attempt to re-add agents was executed with agent 1.6 and 2.6 being added, 3.6 was no longer available.

TBRs were submitted for agents 1.6 and 2.6 to run a report 1/sec for counts of 60, 120, and 180. Each TBR was run to completion before another TBR was started. The Message Groups per Minute panel reflected the messages at the 60 and 120 counts, but the display did not complete for 180 counts. At total of 134 messages were noted on the display.

Similar behavior was noted with the Agents tab Print report option and the Monitor tab Received reports. Refer to Issue 276.

A request for a BP agent full report was created using the Build tab, submitted through the Agent tab, and the results were viewed on the Agent and Monitor tabs.

The report results displayed on the Agents tab corresponded to the ADM (Bundle Protocol Agent Application Data Model draft-birrane-dtn-adm-bp-03). The report values were reviewed in the Monitor tab Received Reports panel. The data values appeared to be present in this panel, but most of the values listed in the UVAST column were specified as UINT in the ADM. The database table, vw_rpt_entries, for this report corresponds to the Received Reports for the UVAST data.

The database table vw_rpt_entries has columns for UINT and UVAST values.

From Asynchronous Management Protocol draft-birrane-dtn-amp-08:
• UINT: unsigned integer: UINTs are unsigned integers from uint8_t integer up to uint32_t.
• UVAST: unsigned integer: VASTs are unsigned integers up to integer uint64_t.

Is there a reason for storing and displaying these values as UVAST rather than the specified UINT in the ADM?

The Build tab page refresh is not helpful when scrolling through a long list of transcoder log IDs. The refresh places the focus at the top of the page and the log entry being reviewed must be found again.