feat: add support for core-data endpoints

[siggiskulason]

This commit adds support for the event and reading endpoints.

edgex-cli event add
edgex-cli event count
edgex-cli event list
edgex-cli event rm

edgex-cli reading count
edgex-cli reading list

the count and list commands support the -j argument to return the raw json result, so that it's possible to do

./bin/edgex-cli reading list -j | jq '.'

This commit also updates all output methods to use fmt.Print rather than cmd.Print, as the
cmd.Print method uses stderr by default instead of stdout - and it's really meant just for usage and error messages.

Signed-off-by: Siggi Skulason siggi.skulason@canonical.com

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-cli/blob/master/.github/Contributing.md.

What is the current behavior?

V2 core-data endpoints are not supported

Issue Number:

fix #391
fix #386

What is the new behavior?

event and reading commands are now supported

Does this PR introduce a breaking change?

• Yes
• No

New Imports

• Yes
• No

Specific Instructions

Are there any specific instructions or things that should be known prior to reviewing?

build and run with

make tidy
make build
./bin/edgex-cli

Other information

[tonyespy]

Overall this looks good, and the new commands seem to work as advertised. That said, I'd added a number of comments inline which need discussion.

The only global comment I have is that the date/time format used (RFC1123) results in really long strings. I would suggest using RFC822 instead...

[siggiskulason]

@tonyespy - thanks for the review. I've updated the implementation as suggested and responded to the comments, including changing the format to RFC822

[tonyespy]

Thanks for making the changes:

• switch to using -d as the short arg for device or core data; use -v for verbose
• use RFC822 for date/time display
• added a -t arg for the event add command

A couple of comments/notes that we should discuss on Fri.

• Maybe it's worth updating the ADR to note the switch from -d to -v?
• The ADR says that -v will no longer trigger the output of response JSON, however when I specify -v for event list, I see "Request" which is JSON, and then the URL (i.e. the request URL). I guess I assumed that -v would just trigger more fields to be pretty printed? I'm not saying this is wrong, so just wanted to check with you...
• Should the default event list output at least show how many readings the event contains?
• It looks like Core Data doesn't do any validation of devices, profiles, or source names when a new event is added (@lenny-intel is there a setting to cause Core Data to validate these names)?
• I didn't expect event add to create a reading if -r wasn't specified. Was that by design?
• If I add an event with the following command, the actual source name is being truncated either by the client or Core Data itself to just "ource":

$ ./bin/edgex-cli event add -d my-device -p my-profile -source my-source
$ ./bin/edgex-cli event list
Origin               Device     Profile     Source
14 Oct 21 19:46 EDT  my-device  my-profile  ource

[siggiskulason]

Thanks for the review, @tonyespy

• Maybe it's worth updating the ADR to note the switch from -d to -v?

Yes - although it's now been approved and merged... Let's discuss.

• The ADR says that -v will no longer trigger the output of response JSON, however when I specify -v for event list, I see "Request" which is JSON, and then the URL (i.e. the request URL). I guess I assumed that -v would just trigger more fields to be pretty printed? I'm not saying this is wrong, so just wanted to check with you...

Yes, this was wrong. I've now updated it. There are really three possible combinations

1. no arguments: minimal list of fields in a table
2. -v:list of all fields in a table
3. -j: json

Test by trying:

./bin/edgex-cli event list
./bin/edgex-cli event list -v
./bin/edgex-cli event list -j | jq '.'
./bin/edgex-cli reading list
./bin/edgex-cli reading list -v
./bin/edgex-cli reading list -j | jq '.'

• Should the default event list output at least show how many readings the event contains?

Yes, I've added that now. The default shows number of readings, the verbose shows the actual readings array as well.

• It looks like Core Data doesn't do any validation of devices, profiles, or source names when a new event is added (@lenny-intel is there a setting to cause Core Data to validate these names)?

• I didn't expect event add to create a reading if -r wasn't specified. Was that by design?

Yes. The V1 edgex-cli had 0 as the default value for -r. However, when I do that, I get an error from the SDK

request failed, status code: 400, err: {"apiVersion":"v2","message":"*requests.AddEventRequest json decoding failed","statusCode":400}

and the syslog shows

level=ERROR ts=2021-10-18T13:24:15.50693862Z app=core-data source=http.go:47 X-Correlation-ID=55920f52-291d-4565-8c85-20c2ceb9884d msg="*requests.AddEventRequest json decoding failed -> AddEventRequest.Event.Readings field should greater than 0"

So I can only assume that adding an event with no readings is not supported in the SDK, @lenny-intel ?
I therefore set the default value of readings to 1, not 0

./bin/edgex-cli event add -h

Create an event with a specified number of random readings

Usage:
  edgex-cli event add [flags]
...
  -r, --readings int     Number of sample readings to create (default 1)

• If I add an event with the following command, the actual source name is being truncated either by the client or Core Data itself to just "ource":
  Yes, because you use -source, not --source or -s, so that's to be expected

$ ./bin/edgex-cli event add -d my-device -p my-profile -source my-source
$ ./bin/edgex-cli event list
Origin               Device     Profile     Source
14 Oct 21 19:46 EDT  my-device  my-profile  ource

[lenny-goodell]

• It looks like Core Data doesn't do any validation of devices, profiles, or source names when a new event is added (@lenny-intel is there a setting to cause Core Data to validate these names)?

@tonyespy , I don't think that exists any more. Used to be an option in V1.
@cloudxxx8 , I think we removed the Validate capability that was in V1 correct?

[lenny-goodell]

So I can only assume that adding an event with no readings is not supported in the SDK,

@siggiskulason , @tonyespy , correct V2 Core Metadata validate expects at least one reading when adding an Event. No longer supports Reading'less Events.

[lenny-goodell]

LGTM

[lenny-goodell]

recheck

[siggiskulason]

Rebased...

[tonyespy]

Thanks for your changes, looks good to me!

Two things we can follow-up on later:

• I still don't find the output of -v very useful
• I would like to find out what happened to the event validation logic. @lenny-intel suggested that the validation logic in v1 wasn't forward ported to the v2, but I didn't seen an answer from @cloudxxx8 about this. I guess in the grand scheme of the things its not the end-of-the world if events can be pushed into Core Data with non-existent devices, profiles, or source names, but I would like to understand why we decided not to implement this (if the logic actually existing in V1).