Update simple_edge_discovery.yaml

[Kevsy]

Fixes camaraproject/SimpleEdgeDiscovery#21 Fixes camaraproject/SimpleEdgeDiscovery#20 Fixes camaraproject/SimpleEdgeDiscovery#19 Fixes camaraproject/EdgeCloud#207 Fixes camaraproject/SimpleEdgeDiscovery#18 Fixes camaraproject/SimpleEdgeDiscovery#17 Fixes camaraproject/SimpleEdgeDiscovery#16 Fixes camaraproject/SimpleEdgeDiscovery#15 Fixes camaraproject/SimpleEdgeDiscovery#14

Also

• expands the basepath to the full API name, which seems to follow convention (it is not strictly defined in Design Guidelines)
• changed the example so it does not name a specific company
• incorporated spelling/linting changes per camaraproject/EdgeCloud#222 and camaraproject/EdgeCloud#223

[Kevsy]

Note: please do not merge/approve until we know the result of #197

[trehman-gsma]

Hi @Kevsy,

We're currently developing test scripts that are focused on technical conformance to the Simple Edge Discovery specification. The main emphasis is on conducting input field-by-field testing (rather than functional validation). Please see the table below for an overview. We can contribute these as Gherkin test cases but we're unsure whether the focus point is relevant. What do you think? cc @deeokonkwo

Input	Expected result
Perform a request that is missing a filter parameter	Filter is required in the specification so a 400 Bad Request is expected as a response – with response body as per specification
Perform a request that contains an invalid filter value	Only “closest” is allowed as a filter value in the specification so a 400 Bad Request is expected as a response – with response body as per specification
If IP address is supported as a device identifier –Perform a request with an IP-Address that does not match any of the required patterns	400 Bad Request – body as per the “Invalid Header Format: IP-Address”
If IPV4 is supported as a device identifier – Perform a request with a valid IPV4 value	200 OK– with response body matching the schema in the specification
If IPV4 is supported as a device identifier – Perform a request with an unknown IPV4 value	404 Not Found – response body as per the "No device found for the specified parameters" example
If IPV6 is supported as a device identifier – Perform a request with a valid IPV6 value	200 OK– with response body matching the schema in the specification
If Network Access ID is supported as a device identifier – Perform a request with an invalid Network Access ID format (i.e. a non-3GPP format)	400 Bad Request – body as per the “Invalid Header Format: Network-Access-Identifier” example
If Network Access ID is supported as a device identifier – Perform a request with a valid Network Access ID value	200 OK– with response body matching the schema in the specification
If Phone-Number is supported as a device identifier – Perform a request with an invalid phone number pattern	400 Bad Request – body as per the “Invalid Header Format: Phone-Number” example
If Phone-Number is supported as a device identifier – Perform a request with a valid phone number that starts with a “+” prefix	200 OK– with response body matching the schema in the specification
If Phone-Number is supported as a device identifier – Perform a request with a valid phone number that does not start with a “+” prefix	200 OK– with response body matching the schema in the specification
If Phone-Number is supported as a device identifier – Perform a request with an unknown phone number	404 Not Found – response body as per the "No device found for the specified parameters" example
Perform a request with all applicable device identifiers with valid values	200 OK– with response body matching the schema in the specification
Perform a request without an access token	401 as per example in spec
Perform a request with an invalid access token	401 as per example in spec

[Kevsy]

@trehman-gsma thanks for that list - I think the API-specific cases are covered in the .feature file in the code/Test_Definitions folder for this PR, but please see what you think.

All the tests for invalid identifiers look useful and comprehensive, I think you should propose them to Commonalities as they will be applicable across multiple APIs.

[hdamker]

Just a question: this PR is changing the API massively (new base path, new endpoint name). Wouldn't it be better to change the version number to something like 0.10.0 to distinct it clearer from 0.9.x?

[deeokonkwo]

Just a question: this PR is changing the API massively (new base path, new endpoint name). Wouldn't it be better to change the version number to something like 0.10.0 to distinct it clearer from 0.9.x?

Agreed, though I'm aware of at least one operator that has been GSMA certified for v0.9.3.

[github-actions[bot]]

🦙 MegaLinter status: ❌ ERROR

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ JSON	eslint-plugin-jsonc	1	0	0	1.35s
✅ JSON	jsonlint	1		0	0.18s
✅ JSON	prettier	1	1	0	0.94s
✅ JSON	v8r	1		0	1.68s
❌ OPENAPI	spectral	9		6	16.91s
✅ REPOSITORY	git_diff	yes		no	0.61s
✅ REPOSITORY	secretlint	yes		no	4.52s
❌ YAML	yamllint	9		1	4.42s

See detailed report in MegaLinter reports

_MegaLinter is graciously provided by _

[javierlozallu]

Hi @Kevin,

Regarding Edge Cloud Zone scheme I was thinking about this:

EdgeCloudZones [ 
       EdgeCloudZone { "edgeCloudId": "string uuid", "edgeCloudProvider": "string", "edgeCloudZoneName": "string"... } 
] 

EdgecloudZones is an array that contains one of several EdgeCloudZone (with their propierties; Id, Provider, Name). I understood that this would be more easy to manage but correct me If I'm wrong so I change the schema in LCM API.

But you have this:

EdgeCloudZones [ 
       EdgeCloudZone { 
               edgeCloudZone { "edgeCloudId": "string uuid", "edgeCloudProvider": "string", "edgeCloudZoneName": "string" } 
       }
] 

In this aproach, EdgeCloudZones in an array that contains one EdgeCloudZone that has one properties (edgeCloudZone) and this property has the Id, Provider, Name.

[Kevsy]

It appears that al the Megalinter errors relate to 'MEC Exposure and Experience Management' and 'Edge_LCM' YAML files. I can see no errors related to Simple Edge Discovery YAML (I merged the previous PRs that had fixed them into 0.9.4)

Note: this behaviour occurs because the megalinter workflow checks every YAML file in /code:

         YAML_YAMLLINT_FILTER_REGEX_INCLUDE: "(code/)"
          OPENAPI_SPECTRAL_FILTER_REGEX_INCLUDE: "(code/)"

So from my perspective the megalinter log has been checked and no Simple Edge Discovery YAML error was reported, so the PR is ready to merge.

[Kevsy]

I have made a new commit to the PR which adds the new Edge Cloud Zone schema as agreed in #215 , and also fixes camaraproject/SimpleEdgeDiscovery#15 and camaraproject/SimpleEdgeDiscovery#14

Megalinter output

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!**

Any linter errors reported by the Linter below relate to other files in the repository.

[Kevsy]

I've updated the PR with the result of discussion #215 (edge cloud zone object definitions) , @javierlozallu please may I ask you to review and merge if approved? This will allow us to include Simple Edge Discovery 0.9.4-rc in the Fall Meta-Release.