EAM: Suggest to add App Instance Name

[gainsley]

Problem description
No human-readable identifier for application instances. Very difficult differentiate between application instances only via UUID.

Possible evolution
Suggest to add a user-assigned name string field to application instances, much like AppManifest has a user-defined name field. This will allow users to easily distinguish between the different application instances they have deployed.

Alternative solution
None.

Additional context
None.

[javierlozallu]

The UUIDs of the application instances are generated by the Edge Platform depending on the Edge Cloud Zones, so it is transparent for the Application Provider and this new parameter should follow the same approach, if we want to add this new parameter we should agree on a data model name for it as well (e.g. AppName-EdgeCloudZoneName).

Some doubts here:

• For one application it is allowed to deploy one app instance per EdgeCloudZone or several app instances per EdgeCloudZone? if multiple instances are allowed then we should add numbering to the data model name.
• The multiple app instances option is based on auto scaling or is something that the app provider can define?
• An application could be composed of multiple microservices, how can we define a naming for this?

[gainsley]

My intent was the name field be user-specified, not server generated. This is the same as AppManifest.Name. The user can choose any name they want, because that name will help them identify the application instance, so there is no specific format beyond being a string.

[gainsley]

Regarding your doubts:

• We allow multiple instances of the same app per edge-cloud-site, but it's really irrelevant here. If the user chooses a name that already exists (and here we need to define the scope, i.e. the name must be unique per edge-cloud-site and per AppProvider, but not necessarily unique globally), then the API fails and the user must choose a non-conflicting name.
• Typically autoscaling is left to Kubernetes, and so all pods that are scaled are still part of a single app instance from the platform's point of view. In any case the name is for the app instance, not individual pods or VMs that may be scaled as part of the single app instance.
• Similarly, the name is for the app instance, not the individual microservices that may be part of the instance, so it doesn't matter how many individual services an app instance may be composed of.

[javierlozallu]

My intent was the name field be user-specified, not server generated. This is the same as AppManifest.Name. The user can choose any name they want, because that name will help them identify the application instance, so there is no specific format beyond being a string.

In that case, developers should define one name per instance, I think it could be complex when instantiating several instances, imagining the case for 50 instances developers have to think of 50 names. And what happens when the instantiation is triggered by an user request, dynamic instantiation, the developer receives a notification to add the name for the instance?

[gainsley]

In that case, developers should define one name per instance, I think it could be complex when instantiating several instances, imagining the case for 50 instances developers have to think of 50 names. And what happens when the instantiation is triggered by an user request, dynamic instantiation, the developer receives a notification to add the name for the instance?

That's a fair point, I would suggest that we allow the user to leave the name blank, in which case the system will either leave it blank, or perhaps fill it in with the appInstanceId.

[gainsley]

To address the issue with mass creation of objects (AppInstances), #256 proposes that the API only targets a single AppInstance due to other issues. Additionally, #312 proposes that names are scoped to the tenant (Provider), so as long as the user is generating names that don't conflict with themselves, there should be no conflicts.