Skip to content

doc: fix Computer/Vermeer examples and improve AI/Server guides - #492

Merged
imbajin merged 4 commits into
apache:masterfrom
lokidundun:vermeer-fix
Sep 17, 2026
Merged

imbajin merged 4 commits into
apache:masterfrom
lokidundun:vermeer-fix

Conversation

@lokidundun

@lokidundun lokidundun commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

Purpose of the PR

Refs #491 — addresses the Computer / Vermeer items, both AI items, and both HugeGraph items in Chinese and English. The Toolchain item and the Release 1.8.0 gate remain open.

Readers currently encounter outdated REST paths and Vermeer ports, an example that reads a graph before its load task finishes, missing navigation links, and undocumented Server startup-timeout controls. This PR corrects those examples and fills the documentation gaps across 12 pages.

Before → after

Before After
Computer result-query examples use /graphs/hugegraph/.... Both languages use /graphspaces/DEFAULT/graphs/hugegraph/graph_read_mode and /graphspaces/DEFAULT/graphs/hugegraph/graph/vertices.
Vermeer REST and Python examples use 8688, without a matching Docker port mapping. Examples consistently use master HTTP port 6688, explicitly publish 6688:6688, distinguish master gRPC port 6689, and include a host-side HTTP check.
The AI follow-up lists omit the Vermeer Python Client guide. Both lists link to the guide beside the existing Python client link.
Server configuration indexes omit the existing backend guides. Both indexes link to HBase, HStore, and RocksDB under a backend configuration section.
The Docker guide does not explain the Server startup wait or how to extend it. Both languages document HG_SERVER_STARTUP_TIMEOUT_S, its 120-second default, 1–86400 range, failure behavior, a 300-second Compose override, and its independence from health-check timing.
The SDK example reads task status once and immediately reads the graph. It polls the created task with a deadline, reads the graph only after loaded, and raises clear errors for failed/canceled tasks, API errors, and polling timeout.

Main changes

  • Update the two Computer REST paths in both quick-start pages.
  • Align Vermeer startup guidance, REST examples, and Python client connections on HTTP port 6688; publish the port in Compose and docker run, and add curl --fail --show-error http://localhost:6688/graphs. Replace non-breaking spaces in the English Compose indentation with normal spaces so the YAML can be copied.
  • Add the Vermeer SDK follow-up link and the three Server backend configuration links in both languages.
  • Document Server startup-timeout validation and failure behavior, with an override example and an explanation of the separate Docker health-check budget.
  • Add bounded polling to the SDK load example, including explicit HTTP timeouts, API error checks, and handling for loaded, error, and canceled. Keep the Chinese and English executable examples identical. Explain that client timeout does not cancel the server task.

Screenshots

The comparisons below render actual Markdown excerpts from f001c1d (before) and de7eb37 (after). They show documentation content changes, not a full Hugo build or live service execution. Chinese equivalents are included in the screenshot package.

Computer: graph-space REST paths

image

Vermeer: HTTP port, Docker publishing and Python client

image

AI quick start: Vermeer SDK navigation

image

Server configuration: backend navigation

image

Docker guide: Server startup timeout

image

Vermeer SDK: wait for the load task before reading the graph

image

Validation

  • Ran 15 offline checks against the extracted documentation examples using the real local SDK with simulated API responses and time: delayed success, immediate success, task failure, cancellation, timeout, task creation failure, task lookup failure, and bilingual executable-code parity. All passed. The original delayed-load examples failed because they read the graph while the task was still waiting.
  • Checked all eight newly added navigation targets in the Chinese and English content trees.
  • Checked the startup-timeout default, accepted range, validation, startup invocation, and Compose environment forwarding against the Server source referenced by the issue (60c8803d5a85943eaa05e74eb37fe7d57b2256a0).
  • Checked load-task terminal states against the Vermeer source (04985bbc9907c7b6c9a8fe8833323df049f9bd9b).
  • git -c core.whitespace=cr-at-eol diff --check f001c1d..de7eb37 passes. The setting accounts for the existing CRLF line endings in the Vermeer pages.

TODO

  • Toolchain: Kafka skipped_line behavior. Decide whether Kafka records should support regex filtering. Either implement filtering before parsing, or remove the unsupported option and examples from both language pages. Align the default-behavior description and add focused coverage for matching and non-matching records.
  • Release 1.8.0 gate: pending PR documentation audit. Inventory candidate unmerged PRs across HugeGraph, Toolchain, AI, and Computer / Vermeer; review user-visible changes; record each PR's Chinese/English documentation impact or no-docs-needed disposition; complete required updates and validation; refresh the inventory before the release branch or tag is cut.

@bitflicker64 bitflicker64 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: no. Summary: Checked the corrected Computer REST paths, the Vermeer 6688/6689 ports and Docker port publishing, the startup-timeout section, and the new polling example against the current hugegraph, hugegraph-computer and hugegraph-ai sources; English and Chinese pages match and I found nothing to change. Evidence: GraphsAPI/VertexAPI graphspace paths, docker-entrypoint.sh timeout validation and docker-compose.yml forwarding, Vermeer master.ini ports, router and task states, pyvermeer TaskResponse fields; ran the Python example against the SDK with a mocked transport for loaded, error, canceled and create-failure cases; site build checks pass.

@imbajin imbajin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: yes. Summary: The revised Vermeer Docker recipes still cannot connect the worker to the master, and the standalone SDK installation flow leaves the demo command pointing at a nonexistent path. Evidence: exact-head source checks against config/worker.ini, the worker gRPC startup path, and the documented installation commands; Hugo CI is green but does not exercise these runtime copy-paste paths.


The framework's runtime configuration can be passed via command-line parameters or specified in configuration files located in the `config/` directory. The `--env` parameter can specify which configuration file to use, e.g., `--env=master` specifies using `master.ini`. Note that the master needs to specify the listening port, and the worker needs to specify the listening port and the master's `ip:port`.

The default master HTTP port is `6688` for REST API and Python clients. Workers connect to the master through gRPC port `6689`. The Docker examples below publish HTTP with `6688:6688`; keep `http_peer=0.0.0.0:6688` in the master configuration.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ The new Docker recipes publish the master's HTTP port but never configure the worker's master gRPC peer. The shipped config/worker.ini defaults to master_peer=127.0.0.1:6689; inside vermeer-worker, loopback points back to the worker, so it cannot register with vermeer-master even though the new HTTP health check succeeds. Set master_peer=vermeer-master:6689 (or 172.20.0.10:6689) in the worker config for both Docker examples, and mirror the fix in the Chinese page.

Never hardcode a real HugeGraph password into a script or a configuration file. Read it from an environment variable or a credential store, as above.

After installing the module you can also run the shipped demo as is:
The bundled `task_demo.py` uses `8688`. Before running it, change the `PyVermeerClient` `port` to `6688` to match the default master HTTP port:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ The standalone installation instructions leave the user in hugegraph-ai/vermeer-python-client (cd at lines 37-40), but this command uses vermeer-python-client/src/..., which resolves to a nonexistent nested path and fails to start the demo. Use python src/pyvermeer/demo/task_demo.py for that install path, or explicitly tell the reader to return to the repository root; mirror the correction in the Chinese page.

@bitflicker64 bitflicker64 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: no. Summary: The new head fixes both points from the last review: worker.ini now points master_peer at vermeer-master:6689, and the demo command is given for both install directories. The Computer graphspace paths, the 6688/6689 ports, the startup-timeout section and the polling example still match the sources. One gap is left in the Compose option: the page runs docker-compose up in the Vermeer root, where the repository already has a docker-compose.yaml without the 6688:6688 mapping and with a different volume string than the one the page tells readers to edit. Evidence: read vermeer/config/{master,worker}.ini, main.go config loading, SayHelloMaster (master takes the worker IP from the gRPC connection) and vermeer/docker-compose.yaml on hugegraph-computer master 04985bb; checked the pyvermeer demo path and root pyproject.toml on hugegraph-ai main 5ee21cc; GraphsAPI/VertexAPI paths and the HG_SERVER_STARTUP_TIMEOUT_S validation on hugegraph master 1a15e76; latest-head CI is green.

Modify `docker-compose.yaml`

- **Volume**: For example, change both instances of `~/:/go/bin/config` to `/home/user/config:/go/bin/config` (or your own configuration directory).
- **Volume**: Change both instances of `~/.config:/go/bin/config` to `/home/user/config:/go/bin/config` (or the configuration directory prepared above).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 This option tells readers to use the existing docker-compose.yaml if there is one, then to build and run docker-compose up -d in the Vermeer root. That directory already has vermeer/docker-compose.yaml (hugegraph-computer master 04985bb), and it is still the old file: vermeer-master has no ports entry, and both services mount ~/:/go/bin/config. A reader who follows these steps with that file gets no host port 6688. The curl check and the Python client (whose page now says Docker deployments must publish 6688:6688) then fail, and this bullet asks them to replace ~/.config:/go/bin/config, which that file does not contain.

Requested change: tell readers to add ports: ["6688:6688"] to vermeer-master and to set both volumes to the prepared config directory, whether they use the repository's docker-compose.yaml or the example above. Alternatively, update vermeer/docker-compose.yaml in hugegraph-computer to match. Please make the same change on the Chinese page.


修改 docker-compose.yaml
- **Volume**:例如将两处 ~/:/go/bin/config 改为 /home/user/config:/go/bin/config(或您自己的配置目录)。
- **Volume**:将两处 `~/.config:/go/bin/config` 改为 `/home/user/config:/go/bin/config`(或上面准备的配置目录)。

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Same gap as on the English page. docker-compose up -d runs in the Vermeer root, where vermeer/docker-compose.yaml already exists. That file has no 6688:6688 mapping for vermeer-master, and both of its services mount ~/:/go/bin/config, so this bullet names a string that is not in the file, and the host curl check and the Python client cannot reach port 6688.

Requested change: tell readers to add ports: ["6688:6688"] to vermeer-master and to point both volumes at the prepared config directory, even when they use the repository's own docker-compose.yaml.

@bitflicker64 bitflicker64 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: no. Summary: Checked the updated Computer graphspace paths, the Vermeer 6688/6689 ports with worker master_peer and Compose/docker run changes, the Python polling example, and the HG_SERVER_STARTUP_TIMEOUT_S section against current hugegraph, hugegraph-computer and hugegraph-ai sources. English and Chinese pages match, and the earlier review points are addressed at this head. Evidence: GraphsAPI/VertexAPI paths; vermeer config/master.ini, worker.ini, main.go defaults, worker gRPC dial and SayHelloMaster peer handling; BaseResp errcode tagging and TaskStateLoaded for load tasks; pyvermeer client, task API and task_demo.py; docker-entrypoint.sh validation regex, start-hugegraph.sh -t failure path and docker/docker-compose.yml forwarding; CI Hugo builds pass on f6ad1de.

@imbajin imbajin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: no. Summary: Reviewed the documentation changes at the exact head; the corrected Computer endpoints, Vermeer Docker and worker connectivity instructions, 6688/6689 ports, startup timeout, Python client flow, and bilingual pages are consistent with the current sources. Evidence: Cross-checked the Server Docker entrypoint and Compose files, Vermeer configuration, routes and task states, and the Python client; five independent checks completed and exact-head CI is green. Score: 9.2/10.

@imbajin
imbajin merged commit 58b99a1 into apache:master Sep 17, 2026
9 checks passed
@imbajin imbajin mentioned this pull request Sep 17, 2026
33 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants