Hello all,

 

We brought this up during the TAG Storage update at this week's TOC session and were asked to start this discussion in the mailing list.

 

This is regarding OpenEBS incubation proposal (https://github.com/cncf/toc/pull/506, currently sandbox). We have been discussing with the OpenEBS team about next steps. Erin Boyd, our TOC liaison, also attended the last TAG Storage meeting when OpenEBS gave a project update. She suggested we bring this up at the TOC meeting.

 

There are mainly three issues:

 

1. Maya branding: OpenEBS has a storage engine called “MayaStor”. Previously there was a concern that the repo includes “Maya” in the name which was part of the MayaData company name.  Since then MayaData was acquired by DataCore. Maya branding is dropped by DataCore. DataCore is happy to donate the Maya branding to CNCF.

Action Item: OpenEBS team will raise a service desk ticket for CNCF to use Maya branding.

 

2. Another issue is regarding ZFS code used in cStor code base. This was a concern previously raised. Now the user space ZFS code has been moved out of cStor code repo, but cStore still has dependencies on an external repo due to the ZFS license issues. We need CNCF to review this again.

 

3. Question to TOC on how to evaluate various engines with different maturity levels when evaluating OpenEBS Incubation Proposal.

There are 2 types of storage in OpenEBS:

1) Local volumes - this is in good state. Lots of production users. Majority of OpenEBS users are using the local volumes.

2) 3 Replicated volumes engines

    a) Jiva stor: Forked from Longhorn. Stable. Just maintain, not add new features. Jiva is not the focus of the roadmap.

    b) cStor: Stable. Slow improvement. Performance is the biggest concern. cStor also has the ZFS challenge mentioned earlier.

    c) Mayastor: It is GA now. Most dev effort is spent here. However we learned from the presentation at TAG Storage that the first production user is only going live this month. For incubation, there is a requirement for 3 production use cases for reference.

 

The question to TOC is how to evaluate a project with various engines with different maturity levels when evaluating OpenEBS Incubation Proposal. If we are evaluating all of them, some may not pass incubation criteria for various reasons.

 

Thanks,

TAG Storage leads

For point 3, we've had similar situations in other projects - OpenTelemetry comes to mind - with different levels of maturity in sub-components / sub-projects. What previous incarnations of the TOC required in these cases was that the level of maturity is clearly signposted to users. Another example: Kubernetes has features in alpha / beta state even though the project as a whole is graduated. We want to encourage projects to innovate, and innovation inevitably means that the new bits are immature.

Great example here of how TOC will need to apply judgement about whether, overall, the level of adoption is sufficient. (I'm also wondering whether the cStor option is widely adopted, or whether, given the performance issues mentioned, it might make sense to encourage users to move to another option so that this approach could be archived?) 

On Thu, Apr 7, 2022 at 11:53 PM Xing Yang <xingyang105@...> wrote:

Hello all,

 

We brought this up during the TAG Storage update at this week's TOC session and were asked to start this discussion in the mailing list.

 

This is regarding OpenEBS incubation proposal (https://github.com/cncf/toc/pull/506, currently sandbox). We have been discussing with the OpenEBS team about next steps. Erin Boyd, our TOC liaison, also attended the last TAG Storage meeting when OpenEBS gave a project update. She suggested we bring this up at the TOC meeting.

 

There are mainly three issues:

 

1. Maya branding: OpenEBS has a storage engine called “MayaStor”. Previously there was a concern that the repo includes “Maya” in the name which was part of the MayaData company name.  Since then MayaData was acquired by DataCore. Maya branding is dropped by DataCore. DataCore is happy to donate the Maya branding to CNCF.

Action Item: OpenEBS team will raise a service desk ticket for CNCF to use Maya branding.

 

2. Another issue is regarding ZFS code used in cStor code base. This was a concern previously raised. Now the user space ZFS code has been moved out of cStor code repo, but cStore still has dependencies on an external repo due to the ZFS license issues. We need CNCF to review this again.

 

3. Question to TOC on how to evaluate various engines with different maturity levels when evaluating OpenEBS Incubation Proposal.

There are 2 types of storage in OpenEBS:

1) Local volumes - this is in good state. Lots of production users. Majority of OpenEBS users are using the local volumes.

2) 3 Replicated volumes engines

    a) Jiva stor: Forked from Longhorn. Stable. Just maintain, not add new features. Jiva is not the focus of the roadmap.

    b) cStor: Stable. Slow improvement. Performance is the biggest concern. cStor also has the ZFS challenge mentioned earlier.

    c) Mayastor: It is GA now. Most dev effort is spent here. However we learned from the presentation at TAG Storage that the first production user is only going live this month. For incubation, there is a requirement for 3 production use cases for reference.

 

The question to TOC is how to evaluate a project with various engines with different maturity levels when evaluating OpenEBS Incubation Proposal. If we are evaluating all of them, some may not pass incubation criteria for various reasons.

 

Thanks,

TAG Storage leads