Engula 2022

[huachaohuang]

Review

Engula was open-sourced in August last year. Engula was just a one-man project with a draft design document back then. But now the project has released two versions (demo 1 and v0.2), and the community has grown up to a dozen active contributors! We are also glad to see that more and more people have started understanding Engula's goals and position.

In the past few months, we did a lot of design, discussion, and prototyping to build better abstractions and implementations. These efforts are valuable and have resulted in a clearer design document and a modular project structure. However, despite what we have done, the project development is far from efficient. There exist some problems we need to address in the next stage:

1. The existing designs and discussions are vague and divergent. One reason is that Engula aims to be extensible and serve different use cases. While the goal is exciting in the long term, it also complicates the design and implementation.
2. Most of the project relies on one maintainer to move forward. The maintainer is not always available and is not omnipotent, of course.
3. The asynchronous part of Rust is too hard to work with in terms of the ecosystem and the interfaces. These bring a lot of uncertainties to the codebase.

To tackle these problems, I propose some solutions as follows. All of these are open for discussion.

Focus on specific goals and designs

The design of a specific Engula engine depends on both the upper-level applications and the low-level Engula modules. But the design of a low-level Engula module, in turn, depends on the engine use cases. These give us a dilemma on the design of different modules. To address this problem, we should set a clearer goal for the next stage.

We can set the goals of Engula 2022 as follows:

• Provide a cost-effective RocksDB-like storage engine on AWS (P0)
• Stabilize the Kernel, Journal, Storage, and Background interfaces (P1)
• Stabilize some part of the asynchronous codebase in terms of the runtime and design patterns (P2)

We focus on stabilizing the interfaces of low-level modules first because they are more general-purpose and easier to reason about. With these stable low-level modules, we can then start designing more sophisticated engines on top of them.

Some more specific goals for different modules:

• Engine
  • Luna should support RocksDB-like interfaces
  • To make things simple, we don't support transactions and partitioning for now
• Kernel
  • Use a Journal for leader election and metadata storage
• Journal
  • Build a leader-based, strongly-consistent Journal:
    • Provide an implementation on fast storage (Local SSD or EBS)
    • Provide an implementation on object storage (for Kernel metadata storage)
• Storage
  • Build a tiered Storage based on a cache storage and an object storage

The detailed design of these modules should be submitted as RFC documents later.

Build an efficient team structure

One side benefit of making Engula modular is that we can also make the team modular along with the project structure. Specifically, we can build a team as follows:

• For each Engula module, there should be one or two owners. A module owner is responsible for driving the module development. Module owners should be able to make decisions about the module without a maintainer, as long as the decisions don't affect other modules.
• There should be two or three maintainers responsible for coordinating different modules and taking care of other aspects of the project.

Asynchronous Rust

TODO: Maybe we don't have to apply asynchronous code to every part of the project? For example, can we build the engine module with synchronous code?

[w41ter]

Maybe we don't have to apply asynchronous code to every part of the project? For example, can we build the engine module with synchronous code?

I think we should continue to apply asynchronous code as long as it is really necessary. Because there still are many works that need to solve for synchronous code, and the compiler lacks a lot of information for optimization.

In addition, the async trait is a problem that is limited by theory. The STM generated by compiler is a DST type, which is used as the method return value. If it needs to be placed on the stack, then the trait object cannot be created, because it isn't object safe. The cargo async_trait using boxes is a compromise solution.

Rest LGTM.

[tisonkun]

One side benefit of making Engula modular is that we can also make the team modular along with the project structure. Specifically, we can build a team as follows

I suggest that we build this module structure virtually and flexibly:

1. It's hard and wasting time to build a permission isolation mechanism to ensure such structure. We can instead elect maintainers and trust them to perform as expected. When a bad manner occurs, you can revoke the permission according to the code of conduct or further governance rules. If we try to build a so-called "zero trust governance", it wouldn't work for an open-source community and simply evict contributors.
2. The Scala community lists out module experts while each expert has even write permission on the repository. It can be a good reference.
3. Many code changes are trivial. Chores and project level works (release, documents, etc.) cannot be divided into multiple modules clearly. "Maintainer" is a high trusted level who we trust can behavior well. If there's proposal/change out of their ability, they should ask for the expert for that domain to make the decision. In Flink, there is a bylaw:

3. Does the Contribution Need Attention from some Specific Committers and Is There Time Commitment from These Committers?

It's hard to determine who is the expert to a specific patch/proposal. Module teams doesn't resolve the problem thoroughly especially when a proposal affects multiple modules. We should try to build governance as simple as possible. Apache Hadoop has 236 committers share the same write permission, but when a committer is unsure whether or not the decision is proper, they will ask for their peers. Trust is important for open-source community, not restriction.

Here is previous discussion in #97 (reply in thread):

I think that more than one maintainers can drive the community go in a way with peer decisions. Here is a recent discussion that happens in ASF Incubator about the bar of committers (and can be referred when thinking of maintainers, too):

• If the contributor has some expertise that’s good. Remember you want this project to survive for a long time. If you set it too high then people will lose interest.
• I suggest the project needs to lower its bar. No one should have to be an expert in all areas to become a committer in a project. It would also be best to consider committers than contribute things other than code.

With our offline discussion, I second that the maintainer group (critical mass) should represent the direction of Engula. If we're currently focusing on the storage engine, growing members in this domain is great. However, an open-source community consists of multiple aspects, which is essential since we're (aimed at) producing software for users, not writing the code itself.

The module structure cannot cover no code contributions also.

[tisonkun]

To be short, you can elect a new maintainer because he/she is an expert on journal module and the activities related to that module are too many to handle. But it doesn't mean that such a maintainer/committer seat binds to the journal module.

[tisonkun]

@huachaohuang I wrote a post on open-source governance (in Chinese, yet). You can read section 2.4 "Adaptability" for what I suggest above. When we turn to move forward governance issue, you can ping me to create a topic according to the situation at the moment.

[huachaohuang]

Thanks for the suggestions. I will take them into account when we really need that in the future.