You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hugegraph.apache.org by "bitflicker64 (via GitHub)" <gi...@apache.org> on 2026/07/26 21:03:25 UTC

Re: [I] InitStore should skip local init when graph.load_from_local_config is explicitly false [hugegraph]

bitflicker64 commented on issue #3118:
URL: https://github.com/apache/hugegraph/issues/3118#issuecomment-5085386264

   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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@hugegraph.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@hugegraph.apache.org
For additional commands, e-mail: issues-help@hugegraph.apache.org