bitflicker64 commented on code in PR #489: URL: https://github.com/apache/hugegraph-doc/pull/489#discussion_r3943616490
########## content/en/docs/guides/hugegraph-docker-cluster.md: ########## @@ -94,34 +147,76 @@ curl http://localhost:8620/v1/partitions # Partition assignment ### Server Variables -| Variable | Required | Default | Maps To | -|----------|----------|---------|---------| -| `HG_SERVER_BACKEND` | Yes | — | `backend` in `hugegraph.properties` | -| `HG_SERVER_PD_PEERS` | Yes | — | `pd.peers` | -| `STORE_REST` | No | — | used by `wait-partition.sh` | -| `PASSWORD` | No | — | enables auth mode | +Unlike PD and Store, the Server entrypoint requires nothing: every variable below is optional and only the ones that are set are written into the config files. A distributed deployment still needs at least `HG_SERVER_BACKEND` and `HG_SERVER_PD_PEERS`. + +| Variable | Default | Maps To | +|----------|---------|---------| +| `HG_SERVER_BACKEND` | template value (`rocksdb`, or `hstore` in the `hugegraph/server` image) | `backend` in `conf/graphs/hugegraph.properties` | +| `HG_SERVER_PD_PEERS` | (none) | `pd.peers` in both `hugegraph.properties` and `rest-server.properties` | +| `HG_SERVER_USE_PD` | `false` | `usePD` in `rest-server.properties` | +| `HG_SERVER_CLUSTER` | `hg-test` | `cluster` in `rest-server.properties` | +| `HG_SERVER_REST_URL` | `http://0.0.0.0:8080` (set in the image) | `restserver.url` | +| `HG_SERVER_MIN_FREE_MEMORY` | `64` (MB) | `restserver.min_free_memory` | +| `HG_SERVER_INIT_STORE_ENABLED` | `true` | `init_store.enabled`, set `false` for PD/HStore deployments where the storage side owns the metadata | +| `HG_SERVER_AUTH_TOKEN_SECRET` | generated when `PASSWORD` is set | `auth.token_secret` in both files, must be at least 32 bytes | +| `HG_SERVER_REQUIRE_AUTH_TOKEN_SECRET` | `false` | when `true`, refuses to start if `PASSWORD` is set without `HG_SERVER_AUTH_TOKEN_SECRET` | +| `PASSWORD` | (none) | `auth.admin_pa`, and runs `bin/enable-auth.sh` to turn auth mode on | +| `PRELOAD` | (none) | `true` preloads the sample graph from `scripts/example.groovy` | +| `JAVA_OPTS` | set in the image | passed to `bin/start-hugegraph.sh -j` | +| `STORE_REST` | `store:8520` | Store REST endpoint that `wait-partition.sh` polls, hstore backend only | +| `HG_SERVER_PD_REST_ENDPOINT` | derived by rewriting `:8686` to `:8620` in `pd.peers` | PD REST peers that `wait-storage.sh` polls | +| `PD_AUTH_USER` / `PD_AUTH_PASSWORD` | `store` / `admin` | credentials `wait-storage.sh` uses against the PD REST API | +| `WAIT_PARTITION_TIMEOUT_S` | `120` | how long `wait-partition.sh` waits for partition assignment | + +`wait-storage.sh` waits up to 300 seconds for a store in state `Up`. That budget is fixed in the script and cannot be raised from the environment. > **Deprecated aliases**: `BACKEND` → `HG_SERVER_BACKEND`, `PD_PEERS` → > `HG_SERVER_PD_PEERS` +`HG_SERVER_INIT_STORE_ENABLED` accepts only the spellings `HugeConfig` accepts, case-insensitively: `y`, `t`, `yes`, `on`, `true`, `n`, `f`, `no`, `off`, `false`. Anything else, `0` and `1` included, aborts the entrypoint. + +The entrypoint writes `docker/init_complete` after a successful initialization and skips re-initialization on later startups, but still re-runs `bin/init-store.sh` so a disabled one revalidates its configuration on every start. + +### Compose Variables + +These are read by the Compose files rather than by the entrypoints: + +| Variable | Default | Purpose | +|----------|---------|---------| +| `HUGEGRAPH_VERSION` | `latest` | Image tag for Server, PD, and Store | +| `HUGEGRAPH_PULL_POLICY` | `missing` | `pull_policy` for those images, use `never` to keep locally built ones | Review Comment: ⚠️ `HUGEGRAPH_PULL_POLICY` is honoured by only two of the four compose files, so "use `never` to keep locally built ones" is wrong for the other two. At 36811483a, `docker-compose.yml:30` and `docker-compose-hstore.yml:31,55,81` expand `${HUGEGRAPH_PULL_POLICY:-missing}`, but `docker-compose-3pd-3store-3server.yml` pins a literal `pull_policy: missing` on the `&pd-common`, `&store-common` and `&server-common` anchors (lines 36, 48 and 76), and `docker-compose.dev.yml` pins `pull_policy: build` (lines 21, 30 and 39). Someone running the HA topology against locally built images is exactly who reads this row, and there the variable does nothing. Suggested cell: `pull_policy` for those images in `docker-compose.yml` and `docker-compose-hstore.yml`, use `never` to keep locally built ones; the 3pd/3store/3server file pins `missing` and the dev overlay pins `build`. Same row at `content/cn/docs/guides/hugegraph-docker-cluster.md:186`. ########## content/en/docs/guides/hugegraph-docker-cluster.md: ########## @@ -94,34 +147,76 @@ curl http://localhost:8620/v1/partitions # Partition assignment ### Server Variables -| Variable | Required | Default | Maps To | -|----------|----------|---------|---------| -| `HG_SERVER_BACKEND` | Yes | — | `backend` in `hugegraph.properties` | -| `HG_SERVER_PD_PEERS` | Yes | — | `pd.peers` | -| `STORE_REST` | No | — | used by `wait-partition.sh` | -| `PASSWORD` | No | — | enables auth mode | +Unlike PD and Store, the Server entrypoint requires nothing: every variable below is optional and only the ones that are set are written into the config files. A distributed deployment still needs at least `HG_SERVER_BACKEND` and `HG_SERVER_PD_PEERS`. + +| Variable | Default | Maps To | +|----------|---------|---------| +| `HG_SERVER_BACKEND` | template value (`rocksdb`, or `hstore` in the `hugegraph/server` image) | `backend` in `conf/graphs/hugegraph.properties` | +| `HG_SERVER_PD_PEERS` | (none) | `pd.peers` in both `hugegraph.properties` and `rest-server.properties` | +| `HG_SERVER_USE_PD` | `false` | `usePD` in `rest-server.properties` | +| `HG_SERVER_CLUSTER` | `hg-test` | `cluster` in `rest-server.properties` | +| `HG_SERVER_REST_URL` | `http://0.0.0.0:8080` (set in the image) | `restserver.url` | +| `HG_SERVER_MIN_FREE_MEMORY` | `64` (MB) | `restserver.min_free_memory` | +| `HG_SERVER_INIT_STORE_ENABLED` | `true` | `init_store.enabled`, set `false` for PD/HStore deployments where the storage side owns the metadata | +| `HG_SERVER_AUTH_TOKEN_SECRET` | generated when `PASSWORD` is set | `auth.token_secret` in both files, must be at least 32 bytes | +| `HG_SERVER_REQUIRE_AUTH_TOKEN_SECRET` | `false` | when `true`, refuses to start if `PASSWORD` is set without `HG_SERVER_AUTH_TOKEN_SECRET` | +| `PASSWORD` | (none) | `auth.admin_pa`, and runs `bin/enable-auth.sh` to turn auth mode on | +| `PRELOAD` | (none) | `true` preloads the sample graph from `scripts/example.groovy` | +| `JAVA_OPTS` | set in the image | passed to `bin/start-hugegraph.sh -j` | +| `STORE_REST` | `store:8520` | Store REST endpoint that `wait-partition.sh` polls, hstore backend only | +| `HG_SERVER_PD_REST_ENDPOINT` | derived by rewriting `:8686` to `:8620` in `pd.peers` | PD REST peers that `wait-storage.sh` polls | +| `PD_AUTH_USER` / `PD_AUTH_PASSWORD` | `store` / `admin` | credentials `wait-storage.sh` uses against the PD REST API | +| `WAIT_PARTITION_TIMEOUT_S` | `120` | how long `wait-partition.sh` waits for partition assignment | + +`wait-storage.sh` waits up to 300 seconds for a store in state `Up`. That budget is fixed in the script and cannot be raised from the environment. > **Deprecated aliases**: `BACKEND` → `HG_SERVER_BACKEND`, `PD_PEERS` → > `HG_SERVER_PD_PEERS` +`HG_SERVER_INIT_STORE_ENABLED` accepts only the spellings `HugeConfig` accepts, case-insensitively: `y`, `t`, `yes`, `on`, `true`, `n`, `f`, `no`, `off`, `false`. Anything else, `0` and `1` included, aborts the entrypoint. + +The entrypoint writes `docker/init_complete` after a successful initialization and skips re-initialization on later startups, but still re-runs `bin/init-store.sh` so a disabled one revalidates its configuration on every start. Review Comment: 🧹 Only the verb is off: the marker is written by the `init-store` command, not by the entrypoint. `InitStore.recordInitComplete()` creates it (`hugegraph-server/hugegraph-dist/src/main/java/org/apache/hugegraph/cmd/InitStore.java:167-187`, called at `:131`) and `InitStore` also returns early when it is present (`:94-99`); `docker-entrypoint.sh:184-185` only computes the path and exports it as `HG_SERVER_INIT_COMPLETE_MARKER`, under the comment "init-store owns the marker". The rest of the sentence is right, including the entrypoint's own guard at `:187`. Suggest "`bin/init-store.sh` records `docker/init_complete` after a successful initialization" in place of "The entrypoint writes". Same sentence at `content/cn/docs/guides/hugegraph-docker-cluster.md:177`. ########## content/en/docs/quickstart/hugegraph/hugegraph-server.md: ########## @@ -352,8 +383,9 @@ Since the configuration (hugegraph.properties) and startup steps required by var > > ```bash > bin/start-hugegraph.sh -> Starting HugeGraphServer... +> Starting HugeGraphServer in daemon mode... Review Comment: 🧹 Follow-up rather than a change to this diff, anchored here because the text it concerns (5.1.2 lines 361 to 373) is outside the hunks. The cn page opens 5.1.2 at lines 341 to 349 with a prerequisite the en page has no counterpart for: set `graph.load_from_local_config=true` in `conf/rest-server.properties`, plus the note that the source default is `false`. That default is real (`ServerOptions.java:355`, read at `GraphManager.java:240`) and the shipped `conf/rest-server.properties` omits the key, so an en reader who follows 5.1.2 verbatim starts a Server that loads nothing from `conf/graphs`, with the sample output right here suggesting otherwise. Since this PR is the sync pass for the page, worth mirroring the cn block into en 5.1.2 above the `backend=rocksdb` snippet at line 366. ########## content/en/docs/guides/hugegraph-docker-cluster.md: ########## @@ -94,34 +147,76 @@ curl http://localhost:8620/v1/partitions # Partition assignment ### Server Variables -| Variable | Required | Default | Maps To | -|----------|----------|---------|---------| -| `HG_SERVER_BACKEND` | Yes | — | `backend` in `hugegraph.properties` | -| `HG_SERVER_PD_PEERS` | Yes | — | `pd.peers` | -| `STORE_REST` | No | — | used by `wait-partition.sh` | -| `PASSWORD` | No | — | enables auth mode | +Unlike PD and Store, the Server entrypoint requires nothing: every variable below is optional and only the ones that are set are written into the config files. A distributed deployment still needs at least `HG_SERVER_BACKEND` and `HG_SERVER_PD_PEERS`. + +| Variable | Default | Maps To | +|----------|---------|---------| +| `HG_SERVER_BACKEND` | template value (`rocksdb`, or `hstore` in the `hugegraph/server` image) | `backend` in `conf/graphs/hugegraph.properties` | +| `HG_SERVER_PD_PEERS` | (none) | `pd.peers` in both `hugegraph.properties` and `rest-server.properties` | +| `HG_SERVER_USE_PD` | `false` | `usePD` in `rest-server.properties` | +| `HG_SERVER_CLUSTER` | `hg-test` | `cluster` in `rest-server.properties` | +| `HG_SERVER_REST_URL` | `http://0.0.0.0:8080` (set in the image) | `restserver.url` | Review Comment: 🧹 "(set in the image)" reads as an image-level environment variable, which this one is not, while the `JAVA_OPTS` row lower in the same table uses the same phrase for one that is. `hugegraph-server/Dockerfile:63` and `Dockerfile-hstore:65` `sed` `restserver.url=http://0.0.0.0:8080` straight into `conf/rest-server.properties`; the `ENV` blocks (`Dockerfile:43-45`, `Dockerfile-hstore:46-47`) carry only `JAVA_OPTS`, `HUGEGRAPH_HOME` and, in the standalone image, `STDOUT_MODE`. `HG_SERVER_REST_URL` itself is unset, which is why the HA compose sets it per node (lines 204, 213 and 222). Suggested default cell: unset; the image bakes `restserver.url=http://0.0.0.0:8080` into `conf/rest-server.properties`. Same row at `content/cn/docs/guides/hugegraph-docker-cluster.md:158`. -- 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]
