Simple Edge Discovery 1.0.0

[Kevsy]

Changed basepath version to /v1
Changed API version number to 1.0.0

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

PR to propose Simple Edge Discovery 1.0.0 (ref minutes of Edge Cloud call 16 April )

Which issue(s) this PR fixes:

Updates version number to 1.0.0 and basepath to /v1

Special notes for reviewers:

Linter output for this file in isolation:

kev@MDC0D157A lint % spectral lint ../EdgeCloud/code/API_definitions/Discovery/simple_edge_discovery.yaml --verbose --ruleset .spectral.yml > eds_1.txt      
(node:38011) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
kev@MDC0D157A lint % cat eds_1.txt 
Found 68 rules (58 enabled)
Linting /Users/kev/Code/Camara/EdgeCloud/code/API_definitions/Discovery/simple_edge_discovery.yaml
No results with a severity of 'error' found!% 

Changelog input

Updates version number to 1.0.0 and basepath to /v1

[github-actions]

🦙 MegaLinter status: ❌ ERROR

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.04s
✅ JSON	eslint-plugin-jsonc	1	0	0	1.41s
✅ JSON	jsonlint	1		0	0.18s
✅ JSON	prettier	1	1	0	0.96s
✅ JSON	v8r	1		0	2.41s
❌ OPENAPI	spectral	9		6	16.86s
✅ REPOSITORY	git_diff	yes		no	0.5s
✅ REPOSITORY	secretlint	yes		no	4.47s
❌ YAML	yamllint	9		1	4.15s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[Kevsy]

^ the linter error shown above relates to the other repository files. See first post for the successful Linter result for the Simple Edge Discovery YAML in isolation.

[javierlozallu]

Hi @Kevsy, just two doubts.

1. I'm not sure if I misunderstood, but you mentioned that you will add X-Correlator for this version as suggested by @FabrizioMoggio, is that right?
2. I was not sure about parameters naming (IPv4-Address, IPv6-Address, Network-Access-Identifier and Phone-Number), because in TI @FabrizioMoggio has (ipv4Address, ipv6Address, networkAccessIdentifier and phoneNumber) that are not defined as parameters as in SED but searching further I found Topics/Questions for Meeting with commonalities #109 which mentions https://github.com/camaraproject/Commonalities/blob/main/documentation/Glossary.md which defines how to use common terms as parameters.

I ask this because for Simple App Endpoint Discovery API we will need to use those parameters and I want to make sure that I use the correct form of naming so that we are in harmony.

[javierlozallu]

I see your explanation in commonalities

By convention HTTP headers are Kebab-Case: RFC 2616, section 5.3. So IPv4-Address uses the same naming style because it is an HTTP Header. "DeviceIpv4Address" is the schema that the parameter is based on (which follows CAMARA UpperCamelCase convention for schema names).

So for point number 2, it's clear to me.

[Kevsy]

Thanks @javierlozallu for your checking!

My mistake 🤦‍♂️ , I've made a new commit with the X-Correlator added to the request and responses.

I linted again locally with the following result:

kev@mac lint % spectral lint ../EdgeCloud/code/API_definitions/Discovery/simple_edge_discovery.yaml --verbose --ruleset .spectral.yml > eds3.txt
(node:67731) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
kev@mac lint % cat eds3.txt 
Found 68 rules (58 enabled)
Linting /Users/kev/Code/Camara/EdgeCloud/code/API_definitions/Discovery/simple_edge_discovery.yaml
No results with a severity of 'error' found!%

[javierlozallu]

@Kevsy I have a comment for:
- simple-edge-discovery-read-closest

I'm adding 3Leg in LCM API and I found in Commonalities-API-design-guidelines that we should follow the structure:
Define a scope per API operation with the structure: api-name:[resource:]action

And for GET methods the action is:
read: For operations accessing to details of the resource, typically GET.
So I think that this change is needed:
- simple-edge-discovery:edge-cloud-zones:read

Let me know what you think

[Kevsy]

Thanks

@Kevsy I have a comment for: - simple-edge-discovery-read-closest

I'm adding 3Leg in LCM API and I found in Commonalities-API-design-guidelines that we should follow the structure: Define a scope per API operation with the structure: api-name:[resource:]action

And for GET methods the action is: read: For operations accessing to details of the resource, typically GET. So I think that this change is needed: - simple-edge-discovery:edge-cloud-zones:read

Let me know what you think

Thanks @javierlozallu - I agree and I have committed the change to the PR.

Lint results

Found 68 rules (58 enabled)
Linting /Users/kev/Code/Camara/EdgeCloud/code/API_definitions/Discovery/simple_edge_discovery.yaml
No results with a severity of 'error' found!% 

👍