EAM API: Support for declarative API and infrastructure-as-code

[gainsley]

Problem description
Some of the Edge Application Management APIs do not have user-assigned unique identifiers, i.e. a "Name". They only have server assigned IDs, i.e. a "UUID". This means an object's unique identity cannot be specified by the user until it has been created and the user has received the ID from the server. This means the APIs cannot be used in a declarative fashion and via infrastructure-as-code, because the contents of declarative yaml/json file would need to include IDs generated by the server for dependencies, i.e. to describe an AppInstance that depends on a specific App. Also because of this, other common tools like Flux and ArgoCD, which are based on infrastructure-as-code, will not be able to manage the EAM APIs.

It also makes testing difficult, as rather than specifying a set of files as the test data (via infrastructure-as-code), the test code needs to be interactive to incorporate IDs of returned objects as the test proceeds, in order to create objects that refer to prior objects (i.e. AppInstances that refer to Apps).

Possible evolution

Suggest that all EAM objects also have a user given Name (string) field, in addition to the server-generated IDs. To avoid conflicts between Names assigned by different tenants, Names shall be scoped to their associated Provider, i.e. App/AppInstance names shall be scoped to the AppProvider, and EdgeCloudZoneNames shall be scoped to the EdgeCloudProvider. This means, for example, to identify an App, you could either use the Name and the AppProvider, or the ID.

All APIs would continue to work via IDs. In order for something like Flux/ArgoCD to work, they would need to go through an intermediate client that can convert Names from infra-as-code yamls to IDs for the APIs. An example of something like this would be a CLI (command-line-interface) client, which can ingest yaml, run List APIs to lookup IDs based on Names, and then run Get/Delete/etc APIs using IDs.

Alternative solution

Get rid of server-assigned IDs in the API altogether and rely only on user-assigned Names. This would require a bunch of API changes, for example paths would change from "GET /apps/{appId}" to "GET /apps/{appProvider}/{appName}". Note the server can still track IDs using objects, but the API would rely on Names.

This would be a much larger change than simply adding Names to each object, but would allow for infrastructure-as-code to work without an intermediate client.

Additional context

Relevant discussion: #255