Process view of modules

[zojw]

In https://github.com/engula/engula/blob/main/docs/design.md, it discloses the modules construct engula

but it seems not very clear how those modules(also user modules) are laid down on different processes(containers) when engula deploy in multiple processes?

This will influence what we do next in deploying engula into k8s, but it seems different folks have a different idea about it in mind, so this is just the starting thread to discuss about it :)

[zojw]

let me give a 🧱 first :)

engula is very flexible, especially user can choose:

• let all function in one process
• each storage/ journal has its process
• one process combines storage/journal
• storage/journal also can be a remote combination of another remote process
• job can be running in standalone process affinity to storage that contains read data.

it seems to have some unclear questions:

• how to choose those options?
• after the user(we) decide on a topology, how to describe topology, who(which module) to set up the initial topology?
• dynamic scale topology is a powerful feature, but which part can be dynamic arrange or all? and which component suitable to observe and dynamic arrange topology~?

[zojw]

maybe for k8s, each storage/journal/job service be a process(pod) may be a better choice, because we start a new pod conveniently, but on-premise may need to put multiple services into one process - -

and can we forbid explicitly using remote storage/journal in a service process, and only allow remote storage/journal be used in the client process, it seems to receive a request then forward to other machine seems to be useless in normal situation 😕 ?(maybe handle migration or wrong routine cache is useful)

[huachaohuang]

maybe for k8s, each storage/journal/job service be a process(pod) may be a better choice, because we start a new pod conveniently, but on-premise may need to put multiple services into one process - -

Yes, I think it can be the standard choice.

and can we forbid explicitly using remote storage/journal in a service process, and only allow remote storage/journal be used in the client process, it seems to receive a request then forward to other machine seems to be useless in normal situation 😕 ?(maybe handle migration or wrong routine cache is useful)

Most systems handle "normal situations" nicely. However, being about to handle the "unnormal situations" is what makes a system shine. For example, if we have a new experimental storage service that we want to test with traffics from the production environment. Then it will be valuable to allow the original storage service to forward a copy of traffics to our new storage service while keeping the original service safe.

[huachaohuang]

@zojw Thanks for putting these things together. Engula is indeed very flexible, which is one of its design goals. While there are many ways to use Engula, I think most users only use it in a few reasonable ways.