Some ideas about config in Engula

[Zheaoli]

Yesterday, @tisonkun and I find a new issue about the Engula when we work on #238. Here's the detail

We want to integrate Engula with a single docker-compose. So we get the first version for the file

version: '3'
services:
  journal:
    image: ghcr.io/tisonkun/engula:nightly
    ports:
      - "10001:10001"
    command: journal run 0.0.0.0:10001 --mem
  storage:
    image: ghcr.io/tisonkun/engula:nightly
    ports:
      - "10002:10002"
    command: storage run 0.0.0.0:10002 --mem
  kernel:
    image: ghcr.io/tisonkun/engula:nightly
    ports:
      - "10003:10003"
    depends_on:
      - journal
      - storage
    command: kernel run 0.0.0.0:10003 --journal journal:10001 --storage storage:10002 --mem

It's seems right, but when we run the hash engine out of the container by using the command cargo run --example hash_engine -- --kernel 127.0.0.1:10003 this will cause some errors like this

    Finished dev [unoptimized + debuginfo] target(s) in 5.85s
     Running `target/debug/examples/hash_engine --kernel '127.0.0.1:10003'`
Error: Kernel(Unknown(Unknown("transport error")))

The root cause is here https://github.com/engula/engula/blob/main/src/kernel/src/grpc/kernel.rs#L38-L40

At the beginning of the Kernel.connect function, the code will request upstream to get the connection config, and then grpc will be created. In our case, the upstream will return the storage:10002 and journal:10001, It's not connectable for us if we want to run something out of the container and we don't have a way to override the config manually but to make a trick docker-compose file.

In my personal opinion, I think maybe we need a way to allow people to override the gRPC connection config manually.

In the future, maybe we need two abstractions for the config code: the Base Config and the Application Config. the Base Config means it's the basic and necessary config(such as gRPC config) to run a component and we can provide enough ways to allow people to load their config based on their own circumstances (using ETCD/ConfigMap/Boostrap Arguments etc.).

[tisonkun]

Thanks for starting this discussion @Zheaoli! I'll take a read in days.

cc @zojw @gaocegege for your information.

[tisonkun]

@Zheaoli I agree with your opinion on resolving configs for dynamic ones. Also, the problem you pointed out exists.

However, from your expression how to abstract the config mechanism is very vague, and I don't see a clear solution to fix the case we meet in docker-compose.

To bring these rough thoughts to valuable suggestion, designs, or implementation, I suggest you to elaborate the config mechanism in your mind, with Engula model in consideration, and how to fix the specific problem elegantly concretely.