feat(raid0): io-engine proto add pool config

[urso]

Related to oep 4011. Introduce Raid configuration and status to the io-engine gRPC.

[abhilashshetty04]

@urso, As a general process can you complete the OEP followed by a design document (comprising HLD, LLD). This helps us in the review process and future reference.

HLD: Includes a high level design plan covering changes in control plane and data plane for the proposed feature. Test plan for the feature.

LLD: Details on low level changes following HLD

On top of my head This feature will require compatibility analyses with Partial rebuild, Performance stats, Pool expansion etc.

cc @avishnu , @tiagolobocastro , @dsharma-dc , @niladrih , @Abhinandan-Purkait

[niladrih]

Thanks for the PR @urso!

I agree with @abhilashshetty04 on the need for a design outline. A high level design should be okay for the time being. A low level design would be a good-to-have.

I also understand that the spread of the mayastor plugin across 4 or more repos may make it inconvenient to formulate the design.

My addition to @abhilashshetty04's suggestion would be to check in implementation code into a feature branch, until we decide on the design.

[tiagolobocastro]

OEP should be merged as implementable first.

Would be good to also add some of the design details to the implementation section of the OEP, covering any gRPC or rest api changes, example:
https://github.com/openebs/openebs/blob/develop/designs/replicated-pv/mayastor/pool-cordon.md

This OEP is also a relatively recent process for us with most things implemented before it was in-place, any feedback and grievances are welcome!

[tiagolobocastro]

these could be enums?

[urso]

yes, it could be an enum. Just used a 'string' here so we don't have to modify the RPC when we want to introduce other raid types.

[tiagolobocastro]

Any advantage to using KB instead of just bytes?

[urso]

In SPDK you configure 'strip_size_kb'. I used to use quantity type and bytes initially, but dealing with conversions it became a little confusing at some point. So to make it easier I opted to pass the value with the unit expected in io-engine/SPDK, while using Quantity-type in the CRD and ensure I have the conversion in one single place only.

[urso]

Thank you for the feedback.

Would be good to also add some of the design details to the implementation section of the OEP, covering any gRPC or rest api changes, example:

Thank you. Yes, I will add some more details about components and RPC being introduced/changed to the OEP.

This OEP is also a relatively recent process for us with most things implemented before it was in-place, any feedback and grievances are welcome!

I'm a little confused where to put the HLD/LLD documentation as I'm not really aware of any examples. Am I supposed to add some more details for the OEP document?

Thank you

OEP should be merged as implementable first.

Makes sense. At which point do we decide it is implementable?

A high level design should be okay for the time being. A low level design would be a good-to-have.

I also understand that the spread of the mayastor plugin across 4 or more repos may make it inconvenient to formulate the design.

My addition to @abhilashshetty04's suggestion would be to check in implementation code into a feature branch, until we decide on the design.

Btw. I do have an implementation ready in my local forks (including io-engine, controll-plane). As the changes touches many components having an MVP implementation upfront did help me quite a bit build an understanding of the code and required changes. If you are curious you can find the implementation here:

• io-engine: https://github.com/urso/mayastor/tree/feature-raid0
• control plane: https://github.com/urso/mayastor-control-plane/tree/feature-raid0

[abhilashshetty04]

Makes sense. At which point do we decide it is implementable?

I see you have made changes to CR suggestions in v1beta3 in feature branch. You can edit the OEP accordingly, resolve all comments.

[tiagolobocastro]

I'm a little confused where to put the HLD/LLD documentation as I'm not really aware of any examples. Am I supposed to add some more details for the OEP document?

HLD is roughly what you have already I'd say, a high level description of the feature request and how it'd be implemented.

LLD is just drilling down a bit more into specifics, containing for example any new gRPC handlers or new types being added, rest api changes, any new services being added, any reconcilers, change of bevahiours, helm chart changes, etc

Makes sense. At which point do we decide it is implementable?

Whenever you think it's ready you just raise a PR with status change in the md file to implementable and give us a nudge :)

Btw. I do have an implementation ready in my local forks (including io-engine, controll-plane). As the changes touches many components having an MVP implementation upfront did help me quite a bit build an understanding of the code and required changes. If you are curious you can find the implementation here:

* io-engine: https://github.com/urso/mayastor/tree/feature-raid0

* control plane: https://github.com/urso/mayastor-control-plane/tree/feature-raid0

Nice, we also do some spikes sometimes before starting, so we can get some more understanding ahead of time.