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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
