Problem description
In AppManifest there is a single Image reference but multiple component definitions. The use case is unclear, as this implies the same image being instantiated multiple times, which does not seem very useful. In general horizontal scaling should be handled by Kubernetes to allow for dynamic scaling. I could see a use case for HA but that typically involves different configurations for each instances (active, standby, etc) and is typically the domain of an application-specific helm chart that this application would reference, rather than try to replicate.
Expected behavior
I expected a single component spec definition for the single image reference. "App bundling", which would bundle multiple AppManifests together as a unit (i.e. a set of database, ui, compute containers) could be handled by another super data structure that references multiple AppManifests.
Alternative solution
Alternatively, AppManifest could become a bundled App definition, allowing for multiple different images and componentspecs. However, this introduces a lot of complexity that would need to be addressed - how to specify how these different images communicate with each other, including passing any certificate/authentication needed. We think it is better to build up in layers and have a simple AppManifest for the single container case and another BundledApp model that can reference multiple AppManifests.
Additional context
Federation EWBI has the same issue in its Artefact model, which is a single image reference with multiple componentspec definitions. In the Federation PoC between EdgeXR, Nearby, and Capgemini, (which has issues documented at https://github.com/edge-collab/federation-ewbi/issues) we agreed to only support a single componentspec in our test implementation, for the same reason that the use case was unclear.
Problem description In AppManifest there is a single Image reference but multiple component definitions. The use case is unclear, as this implies the same image being instantiated multiple times, which does not seem very useful. In general horizontal scaling should be handled by Kubernetes to allow for dynamic scaling. I could see a use case for HA but that typically involves different configurations for each instances (active, standby, etc) and is typically the domain of an application-specific helm chart that this application would reference, rather than try to replicate.
Expected behavior I expected a single component spec definition for the single image reference. "App bundling", which would bundle multiple AppManifests together as a unit (i.e. a set of database, ui, compute containers) could be handled by another super data structure that references multiple AppManifests.
Alternative solution Alternatively, AppManifest could become a bundled App definition, allowing for multiple different images and componentspecs. However, this introduces a lot of complexity that would need to be addressed - how to specify how these different images communicate with each other, including passing any certificate/authentication needed. We think it is better to build up in layers and have a simple AppManifest for the single container case and another BundledApp model that can reference multiple AppManifests.
Additional context Federation EWBI has the same issue in its Artefact model, which is a single image reference with multiple componentspec definitions. In the Federation PoC between EdgeXR, Nearby, and Capgemini, (which has issues documented at https://github.com/edge-collab/federation-ewbi/issues) we agreed to only support a single componentspec in our test implementation, for the same reason that the use case was unclear.