Replies: 8 comments 8 replies
-
@sergiofranciscoortiz I've looked at the definitions in LCM, and how they can be re-used in Simple Edge Discovery. Documentation sectionLCM Text: Analysis: Schema sectionLCM JSON for EdgeCloudZone: Current Simple Edge Discovery schema Proposal:Change LCM to:
Change Simple Edge Discovery to
|
Beta Was this translation helpful? Give feedback.
-
adding @javierlozallu : In PR #208 we discussed the identifier for an individual " We would need unique identifiers, to avoid conflict with other edge cloud providers, e.g. urn:vf:abc123. That identifier would need to be added to the EdgeCloudZoneDetails and returned in the GET \edgeCloudZones array response. So, GET /edgeCloudZones/urn:vf:abc123 would return the details of an individual Edge Cloud Zone." We can incorporate the Identifier URN in the YAML defintion:
(TODO add the schema for the JSON result:
WDYT? And should the array of Edge Cloud Zones include multiple individual |
Beta Was this translation helpful? Give feedback.
-
These are all very good discussions. There's a few different things here being discussed here, so let me comment on them below.
|
Beta Was this translation helpful? Give feedback.
-
I think the given structure to use [ { "edgeCloudZone": "string", "edgeCloudProvider": "string", "status": "unknown", "region": "string" } ] seems fine and may be we can use edgeCloudZoneId for edgeCloudZone. Also, @gainsley proposal for "/providers/{provider}/edgecloudzones/{edgecloudzone}" and the reasoning looks fair. The assignment of the UUID or URN based structure is something we need to agree but my inclination is towards the UUID as parsing and management of such fields if is not difficult but may create management issue at developer. Also in future we need to always work to ensure the given logical interpretation doesnt change which can create difficulties for evolution as it is not an opaque object. The one issue is that as developer I can aggregate information from multiple APIs to represent what a UUID points to in terms of edge cloud zone, location and any other meta information but when there could be many operators in same region (which is also not standard" ) a developer may still need to manage different names, IDs to represents presence of different edge cloud zones in seemingly same location from different providers. But this in my opinion doesnt have a straight solution for now and something that should be handled in future versions of the API. |
Beta Was this translation helpful? Give feedback.
-
I'm also more inclined towards using UUIDs. Plus, I would suggest to include a field This way, the region can be easily consumed as parameter for the Application to configure itself. This can be required by those applications whose content and behavior might change based on the country where the services is offered (e.g., due to whatever legislation or distribution rights). I don't think this can be done with the Device Location API because its needs consent of the device owner. |
Beta Was this translation helpful? Give feedback.
-
Great discussion @Kevsy, @nicolacdnll, @gainsley, @gunjald and as a result we believe that the following changes can meet the criteria for the MVP scope and your insights above. First Option: The method GET /EdgeCloudZone retrieves the object EdgeCloudZone that contains; id, name and provider parameters as in the figure: Second Option: EdgeCloudZoneId will be reused in the POST /app/{appId}/Instance, so developers can instantiate in one or more Zones, depending on the items in the array. (This covers the intent of the MVP API as in figure).
WDYT? |
Beta Was this translation helpful? Give feedback.
-
@javierlozallu my proposal is to remove the Model:
JSON example response to
|
Beta Was this translation helpful? Give feedback.
-
Perfect @Kevsy! I'm going to update the PR #208 with the schema. I think that's all for this discussion so we can close it. (I will be waiting for feedback in #208 so we can merge it). |
Beta Was this translation helpful? Give feedback.
-
Edge Cloud LCM and Simple Edge Discovery define the Edge Cloud zone differently (in the schema and human-readable docs). @Kevsy will investigate how to incorporate the LCM definitions into Simple Edge Discovery.
Tagging @sergiofranciscoortiz
Beta Was this translation helpful? Give feedback.
All reactions