[storage] QoS API proposal

opiproject / opi-api

Open Programmable Infrastructure API and Behavioral Model

Apache License 2.0

31 stars 40 forks source link

[storage] QoS API proposal #273

Closed artek-koltun closed 1 year ago

artek-koltun commented 1 year ago

This patch provides a proposal of API for Volume level QoS and also makes an attempt to initiate a discussion of Device level QoS.

Volume level QoS service leverages the same approach used currently for other services.
Device level QoS limits are provided as a part of frontend device messages, which seem to be a natural place for such limits. This needs to be contrasted with current OPI statements, which assume QoS only as part of middleend and prescribe object-wrapping concept for handling additional services.

Backend QoS shall be provided based on additional discussions.

glimchb commented 1 year ago

API call summary @sanders-mark : starting 7 days review cycle now

glimchb commented 1 year ago

Per the meeting discussion, I was under the impression that we wanted QoS limit per namespace as well, not just the controller i.e. a volume can have specific limits.

@benlwalker @artek-koltun per @jainvipin questions: are namespace covered by storage/v1alpha1/middleend_qos_volume.proto or not ?

benlwalker commented 1 year ago

Per the meeting discussion, I was under the impression that we wanted QoS limit per namespace as well, not just the controller i.e. a volume can have specific limits.

@benlwalker @artek-koltun per @jainvipin questions: are namespace covered by storage/v1alpha1/middleend_qos_volume.proto or not ?

Yes per namespace limits mean per volume in OPI terms and they're enforced by middle-end QoS.

artek-koltun commented 1 year ago

Per the meeting discussion, I was under the impression that we wanted QoS limit per namespace as well, not just the controller i.e. a volume can have specific limits.

Ben is correct. storage/v1alpha1/middleend_qos_volume.proto is very similar to encryption service, which can cover namespaces as well. To create a QoS volume we need to specify original volume (namespace) to apply limits on here

glimchb commented 1 year ago

Ben is correct. storage/v1alpha1/middleend_qos_volume.proto is very similar to encryption service, which can cover namespaces as well. To create a QoS volume we need to specify original volume (namespace) to apply limits on here

Artek/Ben/Vipin - do we need QoS on backend volumes ? Is that the intent of the original question was ?

artek-koltun commented 1 year ago

Artek/Ben/Vipin - do we need QoS on backend volumes ? Is that the intent of the original question was ?

This is the goal of middleend_qos_volume.proto service. We create QoS volume around backened volume (e.g. remote namespace) / middleend volume (e.g. encrypted volume)

jainvipin commented 1 year ago

Ben is correct. storage/v1alpha1/middleend_qos_volume.proto is very similar to encryption service, which can cover namespaces as well. To create a QoS volume we need to specify original volume (namespace) to apply limits on here

Artek/Ben/Vipin - do we need QoS on backend volumes ? Is that the intent of the original question was ?

usually one would limit or provide guarantees to a user/tenant/volume, backend is usually provider owned and infra should honor the user commitments ensuring backend can support what is promised to the frontend.

jainvipin commented 1 year ago

Per the meeting discussion, I was under the impression that we wanted QoS limit per namespace as well, not just the controller i.e. a volume can have specific limits.

@benlwalker @artek-koltun per @jainvipin questions: are namespace covered by storage/v1alpha1/middleend_qos_volume.proto or not ?

yes middle end volume qos should cover namespace... so we should be okay not adding them to the frontend protos.

This PR looks good to me!

glimchb commented 1 year ago

@GottliebNoam @sburla-marvell any comments ?