You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Users may prefer either Podman or Docker as their container runtime.
This change ensures all documentation consistently shows commands for both options, making it easier for users to follow along regardless of their choice.
Built-in TechDocs updated if needed. Note that TechDocs changes may need to be reviewed by a Product Manager and/or Architect to ensure content accuracy, clarity, and alignment with user needs.
How to test changes / Special notes to the reviewer
Given the popularity of Docker, users may prefer either
Podman or Docker as their container runtime.
This change ensures all documentation consistently shows commands for
both options, making it easier for users to follow along regardless
of their choice.
Co-authored-by: Ben Wilcock <benwilcock@gmail.com>
Assisted-by: Cursor
The document states the instructions apply to both Podman and Docker and suggests replacing commands, but the actual examples remain Podman-only. Consider either adding Docker variants (for the key commands) or converting the note into explicit tabs/sections to avoid users missing required substitutions.
> **Note:** All instructions in this guide apply to both Podman and Docker.> Replace `podman compose` with `docker compose` if you are using Docker.
Before you begin, ensure to add the `orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml` file to the
list of `includes` in your `configs/dynamic-plugins/dynamic-plugins.override.yaml` to enable orchestrator plugins within RHDH.
Example:
```yamlincludes:
- dynamic-plugins.default.yaml
- orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml # <-- to add to enable the Orchestrator plugins# Below you can add your own custom dynamic plugins, including local ones.plugins: []
To set up the infrastructure for developing workflow with Orchestrator, you must merge and run these two compose files: compose.yaml and orchestrator/compose.yaml configs.
To get started, run the command below or override the RHDH_ORCHESTRATOR_WORKFLOWS variable in your .env file to
point to your local workflow development directory before running the command.
podman compose -f compose.yaml -f orchestrator/compose.yaml up -d
To make custom changes/configuration to the compose configuration, it is recommended to use a compose-orchestrator.local.yaml by merging the default compose.yaml and orchestrator/compose.yaml to prevent conflicts with version-controlled files.
Run this command to merge compose files:
# NOTE: this will overwrite your existing compose-orchestrator.local.yaml file, if any
podman compose -f compose.yaml -f orchestrator/compose.yaml config > compose-orchestrator.local.yaml
And this command to spin up the containers:
podman compose -f compose-orchestrator.local.yaml up -d
There are three workflow examples to get you started on testing Orchestrator workflow with RHDH Local.
The orchestrator/workflow-examples folder contains example workflows and by default, it is already mounted to /home/kogito/serverless-workflow-project/src/main/resources for SonataFlow configuration in the orchestrator/compose.yaml. The directory contains three workflows: greeting, slack and github. For more information about the workflow and setup, refer to this README.
A suite of workflows exists in this backstage-orchestrator-workflows. Feel free to clone the repository to your local and override the mount directory RHDH_ORCHESTRATOR_WORKFLOWS in your .env file to point to your local backstage-orchestrator-workflows directory. Note: While developing workflows and after making changes to your resources, the pages might error out. Reloading the
page (a couple of times) may fix it. Otherwise, you may have to restart the sonataflow pod by running the command below. This is a known issue.
</details>
<details><summary><a href='https://github.com/redhat-developer/rhdh-local/pull/153/files#diff-15ff791a0aee188446a310b8568f103bade5bccdb4bb3a38dcf24d5ff1875b3cR147-R178'><strong>Command accuracy</strong></a>
Some operational guidance was simplified from a “stop/run installer/start” sequence to a plain “restart”. Validate that a simple restart is sufficient in each context (especially where dynamic plugins may require rerunning the installer), so users don’t end up with stale plugins after following the docs.
</summary>
```markdown
**For app-config changes** (`configs/app-config/app-config.local.yaml`):
=== "Podman"
```bash
podman compose restart rhdh
```
=== "Docker"
```bash
docker compose restart rhdh
```
**For plugin changes** (`configs/dynamic-plugins/dynamic-plugins.override.yaml`):
=== "Podman"
```bash
# Reinstall plugins with new configuration
podman compose run install-dynamic-plugins
# Restart RHDH service
podman compose restart rhdh
```
=== "Docker"
```bash
# Reinstall plugins with new configuration
docker compose run install-dynamic-plugins
# Restart RHDH service
docker compose restart rhdh
```
Why: The suggestion correctly points out a missing docker compose example, which improves consistency with the rest of the documentation and the note added in this PR.
Low
Include Docker restart example
Add a Docker tab with the docker compose restart rhdh command to provide an equivalent example to the existing Podman one for applying configuration changes.
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 6
__
Why: The suggestion correctly identifies a missing docker compose example and proposes adding it, which aligns with the PR's goal of improving documentation consistency for both container engines.
Low
Add Docker log example
Add a Docker tab with the docker compose logs -f rhdh command to provide an equivalent example to the existing Podman one for monitoring logs.
Why: The suggestion correctly identifies a missing docker compose example and proposes adding it, which aligns with the PR's goal of improving documentation consistency for both container engines.
Low
Add Docker startup example
Add a docker compose example for the orchestrator startup command using a tabbed format to match the podman compose example.
-```shell-podman compose -f compose-orchestrator.local.yaml up -d-```+=== "Podman"+ ```shell+ podman compose -f compose-orchestrator.local.yaml up -d+ ```+=== "Docker"+ ```shell+ docker compose -f compose-orchestrator.local.yaml up -d+ ```
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 6
__
Why: The suggestion correctly points out a missing docker compose example, which improves consistency with the rest of the documentation and the note added in this PR.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Users may prefer either Podman or Docker as their container runtime.
This change ensures all documentation consistently shows commands for both options, making it easier for users to follow along regardless of their choice.
Which issue(s) does this PR fix or relate to
Follow-up to #147 (comment)
PR acceptance criteria
How to test changes / Special notes to the reviewer