I believe using a compilation option named ​USE_STORE_HA​ would be more appropriate. Here's why:

​ETCD is a core dependency​ for the current High Availability (HA) feature implementation:

• When HA is ​not enabled, ETCD is naturally not required

• When HA ​is enabled, ETCD ​must​ be used - there's no way to enable HA without it now

Therefore, ​if users want to enable HA features, they should be explicitly required to include ETCD wrapper at compilation time​ without the ability to circumvent this dependency. This ensures architectural consistency and prevents runtime failures.

In summary, I think an option to control the whole HA feature is better.

I believe using a compilation option named ​USE_STORE_HA​ would be more appropriate. Here's why:

​ETCD is a core dependency​ for the current High Availability (HA) feature implementation:

• When HA is ​not enabled, ETCD is naturally not required
• When HA ​is enabled, ETCD ​must​ be used - there's no way to enable HA without it now

Therefore, ​if users want to enable HA features, they should be explicitly required to include ETCD wrapper at compilation time​ without the ability to circumvent this dependency. This ensures architectural consistency and prevents runtime failures.

In summary, I think an option to control the whole HA feature is better.

Good suggestion. Actually, I am also hesitating about using USE_STORE_HA. As you mentioned, this will be easier to understand and more straightforward to use. On the other hand, there are drawbacks, too:

• Currently, ETCD is only used for leader election and leader discovery. Some other features, such as tolerance of client failures, do not rely on ETCD. So, in the future, we may be able to enable these features without etcd.
• We may have alternative choices for the leader election and leader discovery in the future, such as raft, or redis. So users can select which to use.

Hi @ykwd , I'm a bit confused about the difference between USE_ETCD and STORE_USE_ETCD.
What does this means? -DUSE_ETCD=ON -DSTORE_USE_ETCD=OFF.

Hi @ykwd , I'm a bit confused about the difference between USE_ETCD and STORE_USE_ETCD. What does this means? -DUSE_ETCD=ON -DSTORE_USE_ETCD=OFF.

It is indeed a little confusing. Let me explain:

• USE_ETCD means transfer engine uses etcd as its meta server. Other choices for the meta server include redis and HTTP server.
• STORE_USE_ETCD means mooncake-store uses etcd for master server's failover, such as leader election and leader discovery. Currently, the failover feature only supports using etcd as its backend.
• Setting USE_ETCD to ON and USE_ETCD_LEGACY to FALSE or setting STORE_USE_ETCD to ON will compile the go interface for accessing etcd, which depends on go.
• Setting USE_ETCD_LEGACY to ON will compile the c++ interface for accessing etcd from transfer engine. But as the maintenance of c++ interface is less active compared to the go interface, this is named as legacy. Currently store does not support this option.

You can take a look at this PR as a reference for adding a CI test(#473), so we can make sure it builds successfully without needing Go installed

I updated the readme doc to make it less confusing

You can take a look at this PR as a reference for adding a CI test(#473), so we can make sure it builds successfully without needing Go installed

Good idea. Given that the build-without-store task in the CI test(#473) contains a large amount of code, we may want to use a matrix strategy to reuse it across different compile options.