EdgeCloud LCM API - How to enable computing resources selection: Flavors or dynamically

[javierlozallu]

According intent 5 of the API, developers can set computing resources (vCPU, Memory, Storage, GPU. For the MVP we propose to start with these components).

Currently AppManifest could contains implicitly those components when a helm chart is provided. But this is limited to that type of apps, so we need to enable the selection for VM and Container apps.

We think that in the POST /app method, computing resources should be set up. Because as our understanding, Developers have to define the computing resources that their app needs in order to have a good performance in all the zones where the app is being instantiated.

Developers define in the POST /app How (minimum computing resources) and What (app in container/vm) they want to instantiate.

In the first version of the API, the concept of flavor was used. We think that for this MVP version we can add dynamically parameter, because if flavor is used it means that somehow Developer needs to know the flavor types available in the Operator Platform at a Zone level, this could be provided in the GET /edge-cloud-zone method but adding that maybe brings more complexity to the integration with Simple Edge Discovery. @Kevsy

How do you think we should enable the computing resources selection?

[gainsley]

We have found flavors to be less portable. They really only apply when creating VMs. Additionally, each EdgeCloudZone may have its own set of flavors, so either you can't set a flavor in the App definition, or you need to have a common set of flavors which then get mapped to the EdgeCloudZone's flavors (but often the mapping is not exact).

I would suggest instead to define a resources component, which has vcpu as a string of format #.### (i.e. kubernetes style); memory in either a fixed unit (Mb) or as a string with units; storage (probably as a string with units), and GPU.

The resources component can then be added to the App definition either as a minResources or requiredResources field.

[javierlozallu]

Sounds good for us. If we understood correctly the input would be something like this:

In description the units for each component is specified.
WDYT?

[gunjald]

I agree with the issue related to the common definition of the flavor across the edge cloud zones from different providers and even it is not a standard with hyperscalers as of now.

Also for the Helm or docker-compose type applications the resource requirements could be part of the yaml file itself but then the API platform will need to open it to figure out the right environments where the app can be successfully launched meeting the given resource requirements.

So i think we should also discuss about these cases apart from simple VM or containers type of applications.

[javierlozallu]

As discussed on the last meeting, Flavors are discarded because of the complexity to standardize it.
We can have two approaches:

• VM and Containers (Traditional deployments)
• Helm Charts, Docker-Compose, others(?) (Orchestrated deployments)

As I see, maybe we want to manage this as different ways to send the app information. Current we only have the AppManifest but AppFile could be added where oneOf is required.

AppManifest is for traditional deployments.
AppFile is for orchestrated deployments

WDYT? What proposal/approach do you have in mind?

[gunjald]

I think it is a valid point to keep two different objects for different packaging types. The challenge for applications of types Helm or docker-compose is that the individual components and their resource requirements are defined inside and difficult to derive by just looking at the content of these packages.

Also typically as an app developer I may be having a cluster either created or known upfront about its characteristics e.g., number of workers, resource specifications of worker etc and in most of the cases I know the components would be able to run one or the other worker node of this cluster. Similarly for docker-compose the expectation would be that as a developer I know which docker host I am going to run a docker compose app and the docker host has that much of resources as needed by the application.

The important point i want to make is that for such applications there is a notion of resource awareness that developer knows for example it has a cluster or docker host already created by services from telco operator and could be given an identifier that refers or associates to those resources.

These resource identifier which could e.g. refer to clusters or docker hosts etc can be referenced in the current proposal for specifying required resources and there may be APIs to retrieve the identifiers by developer for these resources. Later on even creational API e.g. cluster creation, VMs with docker stack can be evolved which will fill up the gap that exists as of now.

In that case for simple VM or containers the APIs can carry the attributes like traditional deployment containing the CPU, memory, storage etc as the parameters while the AppFile may have information about the cluster or docker hosts for Helm or docker compose apps.
It is just some of my thoughts but will like to know opinions from all group members.