InitStore should be able to skip local init in PD/HStore deployments

[bitflicker64]

Problem

bin/init-store.sh always runs full local setup (scan ./conf/graphs, init non-hstore backends, create admin user). That is right for standalone / tarball installs.

For HStore / PD mode the storage side already owns metadata. Server should start and register with PD. Forcing a full local init on every path makes Kubernetes and Helm harder than they need to be (one-shot Jobs, skip-init workarounds on Server pods).

There is already a Server option for local graph config:

• key: graph.load_from_local_config
• ServerOptions.GRAPH_LOAD_FROM_LOCAL_CONFIG
• used by GraphManager when deciding whether to load graphs from ./conf/graphs

InitStore does not look at that flag today.

Proposal

Teach InitStore to honor the same property, with standalone-safe defaults:

rest-server.properties	init-store
key unset (current shipped defaults)	full init (same as master)
explicit false	no-op, WARN, exit 0
explicit true	full init

Details:

• Skip only when the key is present and false. Missing key must not skip. ServerOptions typed default is false for GraphManager; treating "missing" as skip would break bare tarball init-store.sh.
• Map Docker env HG_SERVER_LOAD_FROM_LOCAL_CONFIG into rest-server.properties (the file init-store.sh already passes to Java).
• Helm / distributed can set the env (or property) to false so Server does not re-init local storage.
• No change to the ServerOptions default itself.

Scope

In scope:

• InitStore.java early exit
• Docker entrypoint env mapping
• unit tests for unset / false / true

Out of scope:

• Helm chart Job / HG_SERVER_SKIP_INIT changes
• util.sh / check_port / lsof (tracked separately, e.g. refactor: replace lsof port preflight with ss/netstat #3105)
• changing GraphManager behavior beyond sharing the existing option name

Why this shape

Community still supports standalone and multi-backend installs, so default behavior of init-store should stay as it is today. Distributed / HStore needs an explicit opt-out so cluster installs do not fight local init.

Related

I can open a PR that implements the above once this issue is filed.

---

Update: dedicated option instead of reusing graph.load_from_local_config

The proposal above reuses graph.load_from_local_config. #3119 implements a
dedicated init_store.enabled instead.

graph.load_from_local_config governs whether GraphManager loads graphs from
./conf/graphs. Whether init-store should run is a different decision, and a
deployment can reasonably want one without the other. Overloading one key for
both would have made the two impossible to set independently later.

The behavior table is otherwise unchanged: key unset means full init, explicit
false is a no-op, explicit true is full init. The Docker env variable is
HG_SERVER_INIT_STORE_ENABLED.

The entrypoint auth-bootstrap work that shared the #3119 branch has moved to
#3133.

[bitflicker64]

Update: the implementation in #3119 deliberately departs from the proposal above, on review feedback from @imbajin.

This issue proposes reusing graph.load_from_local_config, distinguishing "key unset" from "explicitly false" with a containsKey() check. The objection is that the property already has a meaning, whether GraphManager loads graph definitions from the local directory, and its declared default is already false. Giving it a second contract means any existing config that materializes that default explicitly would silently stop initializing the backend and the admin account on standalone RocksDB/HBase installs, after which Docker records init_complete as though init had succeeded.

So the PR adds a dedicated init_store.enabled option instead, defaulting to true:

init_store.enabled	init-store
unset (shipped defaults)	full init, same as master
true	full init
false	no-op, WARN, exit 0

The standalone-safety goal is unchanged, and it no longer depends on a containsKey() distinction. graph.load_from_local_config and GraphManager are untouched.

One clarification on the motivation, since the original text under-explains it. The Docker flag file docker/init_complete lives in the container's writable layer, and no compose file mounts a volume over it. That means docker restart preserves it and init-store runs once ever, but a Kubernetes container restart or pod reschedule starts a new container from the image, so the flag is gone and full local init runs against a PD/HStore cluster on every Server pod restart. A file-based guard cannot fix this, because the problem is that the file does not persist. That is why the decision has to come from configuration.