Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New fields for verision v0.0.2 #4

Open
SteGala opened this issue Aug 9, 2024 · 0 comments
Open

New fields for verision v0.0.2 #4

SteGala opened this issue Aug 9, 2024 · 0 comments

Comments

@SteGala
Copy link
Collaborator

SteGala commented Aug 9, 2024

Hi everyone,

I summarize here the feedback from the internal review process of the REAR data model, highlight what might be included in the next release.

Flavor data model

  • SLA/SLO. There's currently no support for Service Level Agreement in the REAR data models. The Flavor might be the perfect candidate to host such information.
  • The price is currently represented as <amount, currency, period>. The period is currently considered as "for how much time the resources will be available". This is because the only available purchase option right now is "pay up front". No "pay-per-use" model is currently implemented. I believe the price of the Flavor must be refined to include at least these two purchase options.

K8SSlice

  • When we describe the amount of resources of the slice (CPU, GPU, ...), it is not possible to specifiy how these resources are organized (e.g., how many nodes?). It might be relevant because it makes a big difference if the resources come from the aggregation of 10 servers or 2. To this end, I think a field like "number of physical servers" might be helpful. Also considering the features introduced by the latest release of Liqo which allow to create multiple virtual nodes instead of just one.

Sensor

Currently, a sensor is considered to be a passive entity to gather data from. Actuators are not included in the picture. In the next release we may need to either create a new data model for actuators or manage to re-use the sensor model to include also actuators (among the two options I personally prefer the first).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant