Closed RichiH closed 9 months ago
kmova
commented
1 year ago Hi @RichiH. Reached out in the community slack channel. The feedback I got it is the project is actively being used for the engines that have already reached maturity - so the number of commits to those are less. With regards to Mayastor engine - there is active development and adoption.
RealHarshThakur
commented
1 year ago Hey @RichiH, as a past contributor of OpenEBS and current end-user at Civo, I'm sad to see this. At Civo, we rely on Mayastor to power most of our products and the performance we get from it means a lot to us. We're quite happy with Mayastor's stability and the support we get from the team too.
vielmetti
commented
1 year ago As I noted in the Kubernetes Slack #openebs channel, I think one of the visible concerns for the project is that there are a batch of Github issues at https://github.com/openebs/openebs/issues that have not been acknowledged in the last 45 days, and another batch (under "closed") that were closed automatically by a bot without being acked in 90 days. Having techinical issues and bug reports and documentation errors be reported and not acked and be automatically closed is not a good look for any project.
kmova
commented
1 year ago Cross posting here for reference: https://github.com/cncf/toc/issues/905#issuecomment-1552336503
The active OpenEBS engine issues are being worked under: https://github.com/openebs/mayastor/issues
kmova
commented
1 year ago Digging a bit more with the existing maintainers - there is growing adoption of Mayastor. If the maintainers have to keep the project active - what is the information that needs to be presented?
Would preparing an annual review be the right way to approach this at this point? https://github.com/cncf/toc/blob/main/process/sandbox-annual-review.md
lukaszgryglicki
commented
1 year ago Just FYI I see activity on the project. For example:
RichiH
commented
1 year ago Thanks everyone! To be clear, the end result of the discussion phase does not automatically need to be a vote; that's why we have the discussion phase.
Cross-references of relevant data:
orville-wright
commented
1 year ago A the global Prod Mgr of OpenEBS, here is some recent major news on adoption.
The project is very much alive and extremely well used by the K8s community. We had a major validation of the project in the last few days. Microsoft Azure Cloud has recognized OpenEBS (Mayastor Data-Engine) as a core enabling technology for their new "Azure Container Storage Cloud Services" and has built their entire new Container storage service stack & offering ontop of the OpenEBS Project (Maystor NVMe Data-Engine).
The Microsoft Azure launch announcement and OpenEBS details are below. In my discussion with the MSFT Azure PM, R&D and Eng teams during the design & evolution of Microsoft's Azure Container service... MSFT revealed that they expect 100'000's - 1,000,000's of Azure Container customers will deploy their new Azure Container Storage services (which are all driven by OpenEBS Mayastor NVMe Data-Engine). It would be somewhat sad to archive the project now that we've just had a major validation milestone event that... (I believe) no other CNCF Container Storage project can claim to have achieved.
Info 1: https://azure.microsoft.com/en-gb/updates/public-preview-azure-container-storage/
MarkCupitt
commented
1 year ago We committed to OpenEbs not realizing that the project was at this point, very sad as it really does meet a huge need in Kubernetes. We are committed to ZFS and openebs is perfect for what we require. For us it was the zfs-local pv but we are looking at mayastor as well .. but it seems we should be looking elsewhere now ..
Our prime concern was the lack of support and testing on recent Kubernetes releases, we are now restricted to 1.26, as zfs-localpv has a bug and it won't deploy on 1.27
May I suggest you add a note on each product page pointing out that this discussion is taking place and save some people some angst to implement a technology that may well disappear?
No one wants to commit to core storage technology if it does not have the support and backing of the developers
avishnu
commented
1 year ago As one of the engineering leaders for OpenEBS, I'd like to assure that OpenEBS is very much active and the parent company is invested full-time on its growth.
As with any long-term projects that undergo changes, we too underwent a leadership change and there could be certain areas where we were not able to focus as much as we wanted to. But we are all learning and becoming better with each passing day.
As regards to supporting the project and it's plethora of data engines, Mayastor is where most of the engineering is currently invested as we believe this to be a game-changer in the Kubernetes containerised storage domain. The Mayastor roadmap will be updated here.
As regards to other data engines like Jiva, CStor and LocalPV variants, majority of them have reached feature-completeness and there are no new features being planned. We will make the best efforts to maintain these engines w.r.t. security and K8s API updates. We will always welcome contributions from our community users and open-source enthusiasts.
RichiH
commented
1 year ago Thanks everyone; it's clear that there's interest in the project, but also that it's not in a fully healthy state.
@RealHarshThakur can you see Civo investing engineering resources in any way?
@MarkCupitt can you, or someone else, confirm, if Kubernetes 1.27, released on April 11, 2023, is supported as of today?
@kmova I couldn't find a Slack message anywhere, could you try again please? As an alternative, we can also have a call via
@kmova going through https://github.com/cncf/toc/blob/main/process/sandbox-annual-review.md does certainly not hurt
@avishnu OpenEBS itself seems largely stale with five releases being
3.7.0's only change is the adding of new maintainers with no new commits in the repository since May 26, three weeks ago as of time of writing. I went back through the commits until early 2021 and it all seemed janitorial.
https://github.com/openebs/mayastor looks a lot better, of course.
It's good to see new maintainers being added https://github.com/openebs/openebs/commit/ac61a817c3af8e3b95edac1cccd3c0741b0806a9
While there was some end user support, it was not a huge outpouring. This is not a deciding factor on its own, but it's still a signal. Other than the initial replies, there was no further information or specific plans for the future over the last few weeks, something I would expect to come from a project which might be archived.
There's other health signals, i.e. I would expect the license scan badge in OpenEBS' readme or the Jenkins integration for Mayastor to be working correctly, or be fixed over the last few weeks.
NB: I am using "expect" in the "that seems like a natural thing to do for a project and matches my experience in the field" not as in "[silently] demand that it must be done".
Does deprecating parts of the overall projects and focusing on other parts make sense from the project's perspective? Is there a path to getting users to contribute directly or indirectly? There's no clear opinion discernible on TOC side at the moment, so I would prefer waiting for more input and data rather than call for, or cancel, the actual vote.
kmova
commented
1 year ago Thanks @RichiH!! Looking forward to connect and review the plan the team has put together to address these concerns.
While all the info provided in the comment is super helpful, we should discuss how to change this perception about the project.
3.7.0's only change is the adding of new maintainers
https://github.com/openebs/openebs is not a code repo, rather a landing/info repo. There is not going to be much commits going in for every release.
The release notes calls out the changes that went in Mayastor and Local PV engines as well as adding new contributors to the project.
avishnu
commented
1 year ago Thanks @RichiH for your inputs and suggestions and @kmova for the clarification about https://github.com/openebs/openebs being a landing project. Can I request to be invited to the call that is being discussed?
MarkCupitt
commented
1 year ago @RichiH I can confirm that openebs-zfs-localpv does not support Kubernetes 1.27, I believe its a relatively straight forward fix, bug report is at https://github.com/openebs/zfs-localpv/issues/437
We ARE using it successfully on Kubernetes 1.26, with no identified issues so far
RichiH
commented
1 year ago @kmova I know it's a top-level repo, yet it used to get a lot more attention, doc changes, etc until a time aligned with a company purchase; same as other repos. "Change of focus/intensity by main company backing a project" is a story often told in Open Source, and certainly relevant signal; and part of why I asked if certain parts are considered feature complete or if partical deprecation and increased focus on a reduced codebase would make sense. But to also be clear: this is more signal, not a deciding factor in and as of itself.
@avishnu yes, of course! @kmova would you be willing to coordinate on OpenEBS side?
@MarkCupitt thanks! Given the spike of activity in late May 2023, maybe that issue will get fixed as well
avishnu
commented
1 year ago v3.6.0 Mar 14 2022 - NB: same date
@RichiH Can I know the source of the date (Mar 14 2022) in this entry? Isn't it Apr 27 2023 as per the release link? In fact all those releases that you have listed, happened in 2023 (except v3.3.0) !!
RichiH
commented
1 year ago @avishnu I took them from https://github.com/openebs/openebs/tags -- this data is taken from the git commit's date, and the respective tags that point to said commits. I confirmed on CLI to make sure the data in GitHub is correct, and noticed that 3.5.0 & 3.6.0 point to the same commit for some reason:
commit abaa6904e3bea46fdad8dba2149e90f0171df219 (tag: v3.6.0, tag: v3.5.0)
Author: Niladri Halder <niladri.halder26@gmail.com>
Date: Tue Mar 14 23:31:49 2023 +0530I can't tell off-hand when the tags were created, but I can confirm that 3.4.0 points to a commit made in 2022:
commit c594593b6199a8d42188e5870e9090fd5dcf329f (tag: v3.4.0)
Author: Glenn Bullingham <glenn.bullingham@datacore.com>
Date: Wed Nov 16 16:46:26 2022 +0000I just realized that GitHub persists the date of when a tag is pushed in the Releases, so as per https://github.com/openebs/openebs/releases the tag for 3.4.0 was pushed in Feb 17, but based on code in main repo which was old at that time. Maybe 9bda22d4810f7ab031536bedd9bd3d47a35fbe0d from Feb 16 was intended to be released? @niladrih might know.
3.5.0 was pushed on Mar 15, 3.6.0 on Apr 27, with the only change according to changelog being Mayastor 2.0.1 -> 2.1.0.
avishnu
commented
1 year ago @RichiH I'd like clarify here (re-iterate what @kmova commented above) that https://github.com/openebs/openebs is NOT a code repository. It is a Landing project and a placeholder for the community guidelines. Commits happen to this repository contents only when are changes to any of these guidelines, which is not very often. As you said above, it was janitorial early 2021 as well and the company purchase event happened much later towards the end of 2021. So, there is no correlation between the two. Please refer to https://github.com/openebs/openebs/releases for accurate information on the releases.
RichiH
commented
1 year ago @avishnu I know that it's a top level repository. Claiming that there's no correlation at end of 2021 is not entirely correct, though
RichiH
commented
1 year ago TOC had an in-person offsite this week and also discussed inactive projects in general and OpenEBS in particular.
After reaching out to TAG Storage Slack channel and based on private feedback, I have asked @chira001 and @xing-yang, TAG Storage co-chairs, if the TAG could come up with specific suggestions and/or requirements of how an active and healthy OpenEBS could look like. TOC will enter a six month observation phase and make a decision based on project actions and community feedback in March 2024.
Also see https://cloud-native.slack.com/archives/C6PK4RLF7/p1694208906778189
kmova
commented
1 year ago Just a quick note regarding this issue. OpenEBS maintainers met with the TAG team at KubeCon NA 2023 to chart out a plan to address the concerns. Will share more details as we solidify the action plan. At a high level, the intent is to focus on the most widely used/deployed engines in production and engines that are CNCF license compliant, simplify the messaging around the active engines.
RichiH
commented
11 months ago During KubeCon Chicago, @kmova and I also found some time to sit together and we talked through the action plan. I believe Datacore / OpenEBS leadership wanted to share this plan in writing soon (relative to the KC meeting) and I understood the intention to be to have tangible goals, dates, and commitments. As mentioned on Slack with Dave Bright (@orville-wright), it would be good to have that sooner rather than later.
For transparency: TOC is internally moving to being more assertive in archival and there will be another TOC offsite middle of February.
amye
commented
9 months ago In today's TOC meeting, the TOC requested a vote to move this to archive.
amye
commented
9 months ago /vote
git-vote[bot]
commented
9 months ago @amye has called for a vote on [ARCHIVAL] OpenEBS (#1051).
| The members of the following teams have binding votes: | Team |
|---|---|
| @cncf/cncf-toc |
Non-binding votes are also appreciated as a sign of support!
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 5months 29days 19h 12m. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
lukaszgryglicki
commented
9 months ago Hi, can I kindly ask to ping me when/if archival is approved? I'll update DevStats then... thanks!
avishnu
commented
9 months ago As OpenEBS maintainers, we'd want to assure that there is adequate activity on all the important repositories and projects. We have clarified some gaps in understanding and came up with an action plan, which has been shared with the TOC. The action plan mainly focuses on communicating clearly on the proposed status of the various OpenEBS engines. It's already work-in-progress. We are requesting for time till February to sort them. Please abstain from the voting till February.
MarkCupitt
commented
9 months ago Thankyou @avishnu VERY pleased to know this.
Regards
Mark Cupitt Global Operations Manager Billrush
orville-wright
commented
9 months ago During KubeCon Chicago, @kmova and I also found some time to sit together and we talked through the action plan. I believe Datacore / OpenEBS leadership wanted to share this plan in writing soon (relative to the KC meeting) and I understood the intention to be to have tangible goals, dates, and commitments. As mentioned on Slack with Dave Bright (@orville-wright), it would be good to have that sooner rather than later.
For transparency: TOC is internally moving to being more assertive in archival and there will be another TOC offsite middle of February.
Hi @RichiH re: the OpenEBS 'Action plan' that was agreed to, Where do you want the do/info sent to ? or posted? - there are so many forums, channels etc. .that it's unclear where it needs to go to get the correct attention/coverage?
Who needs to see it? and where do they need it to be sent to / posted to? - Please advise. Myself, @avishnu @kmova will be happy to make it available. - Thanks.
amye
commented
9 months ago Discussion in 1/16's TOC meeting is here: https://youtu.be/sbJVXrgRdTU?t=420
RichiH
commented
9 months ago Concerns about the health of OpenEBS have been raised since 2022-06-27 at the latest: https://github.com/cncf/toc/pull/506#issuecomment-1166719790
While there have been multiple and repeated statements of intent to revive the project and/or to archive stale portions of it, we saw little action over the last ~1.5 years.
Please note that if the archival vote is successful, it does not prevent anyone from working on OpenEBS and re-applying for sandbox level; matter of fact, that would be the best possible outcome of an archival.
orville-wright
commented
9 months ago Thanks @RichiH for you feedback,
re: the stale portions of the project (Jiva, cStor, NFS-Provisioner). The project team doesn't have any objections to this concept and we are in support of it as it makes good sense. This is definitely where the KubeCon Chicago discussion (with Alex and Xing) were mostly centered on. (note: I was in that meeting).
A key dilemma for the team is that we don't fully understand how (physically) CNCF would split-out and archive off the stale portions while supporting & enabling the modern/active sub-project "Mayastor", enabling it to live-on and continue on as primary project of OpenEBS ?
After meeting with Alex and Xing in Chicago, we've had project team, numerous meetings and many folks felt that 'physically slicing off the stale projects' ... was not what CNCF was asking for; but now... you guys have clarified that this is what you want.
~Dave
Zman2356
commented
9 months ago To the ToC and the OpenEBS user community, Please accept our sincere apologies for putting the OpenEBS project in a position of an archive vote. The product commitment has been there all along, but we lacked the proper community engagement which will be corrected immediately. Please view this short explainer video https://share.vidyard.com/watch/Nw7XBqbCDgraxgiVrbx8pX? Dave Zabrowski, CEO of DataCore Software
edrob999
commented
9 months ago I was the person at KubeCon in Chicago who promised the project team would address issues. Here is what's going on.
OpenEBS is a very active project. I now work for DataCore, and work alongside 20 engineers fulltime on the OpenEBS project, and they are very passionate and proud to work on such a widely used project. Looking at the developer activity counts on cncf.io, outside DataCore another 332 people have contributed to the project in the last year. We know a lot of companies, maybe thousands, use the software in production, including Microsoft - Microsoft Azure Container Service is derived from OpenEBS. The OpenEBS project is alive and very active.
Communication Its clear we have a communication problem. RichiH - I've tried connecting with you on LinkedIn, I would send you my email/phone, so you can reach me if you're not getting through. There are so many slack channels! For me - I'm new here, I'm simply not seeing the questions you're posting, but it doesn't mean I'm ignoring you - please help us fix this.
If the ToC decides to keep the project from being archived, I hope we can designate a single channel - whether its a specific Slack Channel, or GitHub or something else that we use for comms, so this doesn't happen again.
I also hope there is a way we can keep the OpenEBS project from being archived. The project team feel awful, they've put their passion + energy into the project for years, and want to see it move towards incubation and graduation. They are terribly upset that OpenEBS could be archived instead. Ed Robinson
amye
commented
9 months ago /check-vote
git-vote[bot]
commented
9 months ago So far 54.55% of the users with binding vote are in favor (passing threshold: 66%).
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 6 | 1 | 0 | 4 |
| User | Vote | Timestamp |
|---|---|---|
| justincormack | Against | 2024-01-23 16:24:49.0 +00:00:00 |
| RichiH | In favor | 2024-01-16 16:46:22.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-01-16 23:30:28.0 +00:00:00 |
| mattfarina | In favor | 2024-01-17 21:05:46.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-01-19 17:43:06.0 +00:00:00 |
| erinaboyd | In favor | 2024-01-17 22:12:59.0 +00:00:00 |
| nikhita | In favor | 2024-01-23 8:53:30.0 +00:00:00 |
| @rochaporto | Pending | |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kgamanji | Pending |
kmova
commented
9 months ago Just my 2c.
I can see that the code is actively maintained. https://openebs.devstats.cncf.io/d/2/commits-repository-groups?orgId=1&var-period=w&var-repogroups=All&from=now-4y%2Fy&to=now
And anecdotally speaking to different folks - there were atleast two large production users. I wonder if CNCF could actually make sometime to talk directly with those users around the responsiveness of the project maintainers before taking the vote.
It is really unfortunate to see a project that is actively developed and used in production go through this vote due to the lack of community engagement.
(The optimist in me would like to give this https://github.com/cncf/toc/issues/1051#issuecomment-1902074535 a chance. What is another 3 months - to check if the team will come through, instead of rushing the vote asap.)
lukaszgryglicki
commented
9 months ago @kmova you mentioned DevStats - it actually runs using OpenEBS as a storage option.
amye
commented
9 months ago /check-vote
git-vote[bot]
commented
9 months ago So far 54.55% of the users with binding vote are in favor (passing threshold: 66%).
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 6 | 1 | 0 | 4 |
| User | Vote | Timestamp |
|---|---|---|
| erinaboyd | In favor | 2024-01-17 22:12:59.0 +00:00:00 |
| RichiH | In favor | 2024-01-16 16:46:22.0 +00:00:00 |
| justincormack | Against | 2024-01-23 16:24:49.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-01-16 23:30:28.0 +00:00:00 |
| mattfarina | In favor | 2024-01-17 21:05:46.0 +00:00:00 |
| nikhita | In favor | 2024-01-23 8:53:30.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-01-19 17:43:06.0 +00:00:00 |
| @rochaporto | Pending | |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kgamanji | Pending |
lukaszgryglicki
commented
9 months ago /check-vote
git-vote[bot]
commented
9 months ago Votes can only be checked once a day.
RichiH
commented
9 months ago It is clear that there are people who care deeply about OpenEBS and it's also clear that there are large/important users and use cases and no clear replacement. Yet, it's also evident that there's a repeating pattern of a flurry of communication and commitments every time TOC moves towards implementing the policies in place, with a seemingly inevitable fall-off shortly after. We have gone through this cycle repeatedly over the last 19 months.
While there are several possible "official" ways to communicate specific and committed plans -- such as Slack, this GH issue, https://github.com/cncf/toc/issues/905, or TAG Storage, none have been used to communicate said plans. As communicated previously, GitHub is preferred as it's public, searchable, and time-stamped.
The outcome of the TOC vote is not certain either way. No matter the outcome of the vote, a good outcome for the project and the wider community would be a communication of committed plans and then their subsequent execution.
Again, if the archival vote succeeds, the door does not close. While trademark and marketing are impacted, the GitHub repositories are not. Development can, and arguably should, continue. This can also be seen as a forcing function for both the management of existing contributors and large users who are currently not contributing; as a loud cry for help and investment.
An archived project can re-apply for sandbox at any time. As communicated previously this is the best possible outcome of a successful archival vote.
Zman2356
commented
9 months ago @RichiH, you are absolutely correct in your observation as we simply have not communicated as we should have. That will not happen again as I am now holding weekly all hands stand ups and funding a full time community lead (in addition to 20 dedicated devs). I will ask the dev team to post the detailed plan to GitHub as you request. I hope the ToC will see that while the communication has not been consistent, the commitment to the project has been.
avishnu
commented
9 months ago OpenEBS - Project Health Improvements.pdf Sharing the plan and the progress towards the same. Thank you.
RichiH
commented
9 months ago Thanks. For convenience, https://docs.google.com/document/d/1QyWBa1ksJTyv6RawPrD9uJDqz4DEMIhSuTU5xs6OjFI/edit is the direct link the the GDoc underlying the PDF.
edrob999
commented
9 months ago @RichiH Agree that OpenEBS is a useful project, used by a lot of Kubernetes users in production. Also agree the communication needs improvement, and requests haven't been dealt with. As I've watched the project and talked to some of our members, people in the OpenEBS community contribute because they're interested in storage + Kubernetes. Many are not confident to communicate with CNCF on project issues.
I (Ed Robinson) am happy to steward improving this, to understanding the CNCF guidelines, making sure the project agrees a path compliant, communicating with CNCF + resolving issues. I'll also set up a process so that the OpenEBS community can vote for a new steward.
Moving the project to archive doesn't solve the communication problem. It just means someone else has to deal with the problem later. "Kicking the can down the road"
I'm hoping we can keep the project from being archived, and I will actively act as steward to make sure we are communicating, responding, and dealing with requests.
Ed
TheFoxAtWork
commented
9 months ago 👋🏻 Hello everyone, in order to avoid future confusion as to the outstanding requests for OpenEBS and the impetus behind moving to an archive vote, the TOC has pulled together the following information to share with the project and all interested parties.
The TOC has made the decision to bring the OpenEBS project to a vote for archival in keeping with our Archive process; end users were notified on May 17th, 2023 of the proposal to archive.
The Archive process encompasses the TOC evaluating different indicators that were observed by community members and brought to the TOC's attention. Project health is one but not the only indicator the TOC weighed in moving this project to a vote for archive. While the TOC does anticipate project’s to shift their scope in response to contributors’ and adopter feedback, we expect Sandbox projects to experiment and make progress towards incubation, documenting their decisions transparently, demonstrating alignment with CNCF Values, and completing or responding to recommendations provided by the TOC and TAGs to enable the project to be successful within the CNCF.
The TOC has engaged the OpenEBS project on several occasions since this issue and its predecessor were opened on the repo. Issue #905 was filed after a low point of commit activity during the acquisition of Mayadata. It is anticipated companies who donate projects to CNCF could become acquired, which may result in decreased or stalled activity, occasionally withdrawing from a project altogether.
Since OpenEBS was accepted into the CNCF as a Sandbox project, numerous issues with the project have occurred, in varying states of resolution with limited tracking. The OpenEBS project also made several, significant changes to their focus, most notably concerning the storage engines, and finally with the control plane, eventually concentrating its development efforts around Mayastor.
Over several years of discussions with the project, its maintainers, and TAG Storage, the TOC has evaluated the project’s governance, documentation, activity, and general practices against those we expect of a Sandbox project. The last Annual review the project provided to the TOC, prior to removing manual annual reviews (2023) in favor of automation (coming 2024), was in 2021. The project applied to incubation level in 2020, received feedback from TAG Storage in August 2020, January 2021, and March 2022, but ultimately paused the incubation application in June 2022 and subsequently closed in May 2023 after highlighting continued areas of improvement needed by the project to be ready for incubation.
In addition to prior requests for resolution of feedback and action items, the TOC has reviewed the project’s governance practices and documentation, determining that:
the documentation provided to contributors and adopters is out of date, in many cases years out of date
there are inconsistencies and conflicts in statements regarding the current state and stability of its 4 storage engines
non-conformance to the project’s own defined governance regarding adding and removing maintainers
Further, in re-evaluating OpenEBS against expectations of projects in a sandbox status (refer to the Sandbox Annual Review guide introduced with the TAGs in 2023 before removing manual annual reviews) the following is observed:
Typically, the findings and recommendations from sandbox annual reviews are filed with the project as an issue on their repo for tracking to completion, however given the continued recommendations over the past 3 years by TAG Storage and the TOC to bring the project back into alignment with these expectations, the TOC has called a vote to archive OpenEBS.
This vote has been called to place the project in a state of archive. For more information on the expectations of an archive state in CNCF please refer to our Archive Status section, please note that archived projects may continue development in its repositories, ideally with a goal to reapply.
In the event the Archive vote passes, the following recommendations are made to OpenEBS and Mayastor, should they choose to reapply:
In the event the Archive vote does not pass, we fully expect the OpenEBS project to file an issue or series of issues on their repo, cross linked/referenced with this Issue so the TOC may monitor and track the above recommendations and the expectations to conclusion with the OpenEBS project, with substantive progress by the end of August 2024.
We appreciate the OpenEBS project and its maintainers engaging on this issue recently, and thank everyone for their insights, observations, and efforts in bringing this discussion to closure.
As a reminder, the TOC maintains several official communication mediums by which project maintainers, contributors, and interested parties may reach out to the TOC. We may be reached on slack in the #toc channel, by email at cncf-toc@lists.cncf.io or cncf-private-toc@lists.cncf.io (for sensitive matters), through our Repo by filing an issue, or by joining our twice monthly public meetings. This ensures all TOC members are kept apprised of discussions, statuses, and commitments of projects and the TOC. We have several CNCF staff that support the TOC in monitoring these communication methods. Directly contacting TOC members individually is generally discouraged as we perform this function in addition to our regular work and such contact may be lost amid day-to-day tasks, illnesses, holidays, or other events.
edrob999
commented
9 months ago Thanks @TheFoxAtWork for this info. It is the project team's request that OpenEBS is NOT archived. We commit to resolving the issues you have identified, using the cross linked/referenced process you suggest, and making substantive progress before end of August 2024.
I would like to propose an archival vote for the OpenEBS project.
As per https://github.com/cncf/toc/issues/905 , https://github.com/cncf/toc/pull/506#issuecomment-1166719790 , and https://app.slack.com/client/T08PSQ7BQ/C0MP69YF4 there have been substantial concerns about the continued health of the project for almost a year by now, with no equally substantial actions by the project to counteract or alleviate said concerns.
As per yesterday's TOC call, we are already following https://github.com/cncf/toc/pull/1050 in spirit even though it is not accepted yet. The only material difference for this process is that the two week mandatory discussion phase does not trigger immediately after informing the maintainers, the end user community must also be informed prior to the discussion phase beginning. As this is in favor of OpenEBS, I see no issues with applying the updated process. At the active request of OpenEBS maintainers, we can also follow the old process.
CC @gila @GlennBullingham @kmova @nconnolly1 @pawanpraka1 @vishnuitta