vxcontrol/pentagi
1
0
Fork 0
mirror of https://github.com/vxcontrol/pentagi.git synced 2026-07-19 12:11:02 -04:00
Code Issues 45 Packages Projects Releases 9 Wiki Activity

[PR #233] Feat/bedrock config path #255

New Issue
Open
opened 2026-06-06 22:09:54 -04:00 by yindo · 0 comments
yindo commented 2026-06-06 22:09:54 -04:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/233
Author: @salecharohit
Created: 4/4/2026
Status: 🔄 Open

Base: main ← Head: feat/bedrock-config-path

📝 Commits (5)

  • 36b7981 feat(bedrock): add BEDROCK_CONFIG_PATH support for custom provider config
  • 4be1a26 docs: document BEDROCK_CONFIG_PATH in README
  • aeeb98d fix(docker): hardcode BEDROCK_CONFIG_PATH in-container path in compose
  • b1b606d fix(docker): align BEDROCK_CONFIG_PATH pattern with existing providers
  • 2641168 feat(bedrock): auto-seed provider from BEDROCK_CONFIG_PATH on startup

📊 Changes

11 files changed (+276 additions, -11 deletions)

View changed files

📝 .env.example (+1 -0)
📝 README.md (+2 -0)
📝 backend/cmd/ctester/main.go (+1 -1)
📝 backend/pkg/config/config.go (+1 -0)
📝 backend/pkg/graph/schema.resolvers.go (+4 -0)
📝 backend/pkg/providers/bedrock/bedrock.go (+11 -2)
📝 backend/pkg/providers/bedrock/bedrock_test.go (+5 -5)
📝 backend/pkg/providers/pconfig/config.go (+1 -0)
📝 backend/pkg/providers/providers.go (+68 -3)
📝 docker-compose.yml (+2 -0)
➕ glm_flash_bedrock.yml (+180 -0)

📄 Description

Description of the Change

Problem

The AWS Bedrock provider in PentAGI only supported a single built-in config.yml for model and pricing definitions, which is embedded at compile time. This made it impossible to use non-standard Bedrock-accessible models (e.g., GLM Flash via zai.glm-4.7-flash) without recompiling the binary or modifying the source config.

Solution

Introduce a BEDROCK_CONFIG_PATH environment variable that lets users point to an external YAML file to override the built-in Bedrock provider config. When the variable is unset, the existing embedded config.yml is used unchanged (fully backward-compatible). When set, the specified file is read at startup instead.

Key changes:

  • backend/pkg/config/config.go — added BedrockConfig string field mapped to BEDROCK_CONFIG_PATH
  • backend/pkg/providers/bedrock/bedrock.go — DefaultProviderConfig() now accepts *config.Config and branches on BedrockConfig to call either configFS.ReadFile (embedded) or os.ReadFile (external path)
  • backend/pkg/providers/providers.go and backend/cmd/ctester/main.go — updated callers to pass cfg to DefaultProviderConfig
  • docker-compose.yml — propagates BEDROCK_CONFIG_PATH env var into the container and mounts PENTAGI_BEDROCK_CONFIG_PATH (defaults to ./glm_flash_bedrock.yml) at /opt/pentagi/conf/bedrock.provider.yml
  • glm_flash_bedrock.yml — new example config for the GLM 4.7 Flash model (zai.glm-4.7-flash) accessible via Bedrock, with per-agent tuned parameters and pricing
  • .env.example and README.md — documented the new variable

Closes #

Type of Change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • 🚀 New feature (non-breaking change which adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📚 Documentation update
  • 🔧 Configuration change
  • 🧪 Test update
  • 🛡️ Security update

Areas Affected

  • Core Services (Frontend UI/Backend API)
  • AI Agents (Researcher/Developer/Executor)
  • Security Tools Integration
  • Memory System (Vector Store/Knowledge Base)
  • Monitoring Stack (Grafana/OpenTelemetry)
  • Analytics Platform (Langfuse)
  • External Integrations (LLM/Search APIs)
  • Documentation
  • Infrastructure/DevOps

Testing and Verification

Test Configuration

PentAGI Version: latest (main + this branch)
Docker Version: 27.x
Host OS: macOS / Linux
LLM Provider: AWS Bedrock (GLM 4.7 Flash via zai.glm-4.7-flash)
Enabled Features: none

Test Steps

  1. Copy .env.example to .env and set BEDROCK_CONFIG_PATH=./glm_flash_bedrock.yml along with valid Bedrock credentials (BEDROCK_REGION, BEDROCK_ACCESS_KEY_ID, BEDROCK_SECRET_ACCESS_KEY)
  2. Run docker compose up -d (or go run ./cmd/pentagi from backend/)
  3. Confirm the Bedrock provider initializes without error and that zai.glm-4.7-flash is used for agent calls
  4. Remove BEDROCK_CONFIG_PATH and restart — confirm the built-in default config is loaded as before

Test Results

Provider initializes successfully with the custom config; falls back cleanly to the embedded config when BEDROCK_CONFIG_PATH is unset.

Security Considerations

The file path is read at server startup only, using os.ReadFile with the path supplied by the operator via environment variable. No user-controlled input influences the path at runtime. No new network endpoints or permissions introduced.

Performance Impact

Negligible — config file is read once at startup. No change to request-path code.

Documentation Updates

  • README.md updates
  • API documentation updates
  • Configuration documentation updates
  • GraphQL schema updates
  • Other:

Deployment Notes

New environment variable (optional, backward-compatible):

Variable Default Description
BEDROCK_CONFIG_PATH (empty — uses built-in config) Absolute or relative path to a YAML file that overrides the embedded Bedrock provider model/pricing config

Docker Compose: If using a custom config file, set PENTAGI_BEDROCK_CONFIG_PATH to the host path of your YAML file. The compose file mounts it to /opt/pentagi/conf/bedrock.provider.yml and sets BEDROCK_CONFIG_PATH accordingly. A ready-made example for GLM Flash (glm_flash_bedrock.yml) is included in the repo root.

No database migrations or breaking changes required.

Checklist

Code Quality

  • My code follows the project's coding standards
  • I have added/updated necessary documentation
  • I have added tests to cover my changes
  • All new and existing tests pass
  • I have run go fmt and go vet (for Go code)
  • I have run npm run lint (for TypeScript/JavaScript code)

Security

  • I have considered security implications
  • Changes maintain or improve the security model
  • Sensitive information has been properly handled

Compatibility

  • Changes are backward compatible
  • Breaking changes are clearly marked and documented
  • Dependencies are properly updated

Documentation

  • Documentation is clear and complete
  • Comments are added for non-obvious code
  • API changes are documented

Additional Notes

The glm_flash_bedrock.yml included in the repo root serves as both a working config for the GLM 4.7 Flash model and a reference template for users who want to use any other Bedrock-accessible model not covered by the built-in defaults. The YAML structure mirrors the existing embedded config.yml format.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/233 **Author:** [@salecharohit](https://github.com/salecharohit) **Created:** 4/4/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/bedrock-config-path` --- ### 📝 Commits (5) - [`36b7981`](https://github.com/vxcontrol/pentagi/commit/36b7981240d95999140e406101da2bbae0b46e06) feat(bedrock): add BEDROCK_CONFIG_PATH support for custom provider config - [`4be1a26`](https://github.com/vxcontrol/pentagi/commit/4be1a26cba9f3b754e278102d063654ed1a89452) docs: document BEDROCK_CONFIG_PATH in README - [`aeeb98d`](https://github.com/vxcontrol/pentagi/commit/aeeb98dd006ab9187e02f326eea29f7c4427ebc7) fix(docker): hardcode BEDROCK_CONFIG_PATH in-container path in compose - [`b1b606d`](https://github.com/vxcontrol/pentagi/commit/b1b606df7abd89844b128f964a06650082e4096d) fix(docker): align BEDROCK_CONFIG_PATH pattern with existing providers - [`2641168`](https://github.com/vxcontrol/pentagi/commit/264116827d0932a909f1cd38cc1fc4b0f61348ee) feat(bedrock): auto-seed provider from BEDROCK_CONFIG_PATH on startup ### 📊 Changes **11 files changed** (+276 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `.env.example` (+1 -0) 📝 `README.md` (+2 -0) 📝 `backend/cmd/ctester/main.go` (+1 -1) 📝 `backend/pkg/config/config.go` (+1 -0) 📝 `backend/pkg/graph/schema.resolvers.go` (+4 -0) 📝 `backend/pkg/providers/bedrock/bedrock.go` (+11 -2) 📝 `backend/pkg/providers/bedrock/bedrock_test.go` (+5 -5) 📝 `backend/pkg/providers/pconfig/config.go` (+1 -0) 📝 `backend/pkg/providers/providers.go` (+68 -3) 📝 `docker-compose.yml` (+2 -0) ➕ `glm_flash_bedrock.yml` (+180 -0) </details> ### 📄 Description ### Description of the Change #### Problem The AWS Bedrock provider in PentAGI only supported a single built-in `config.yml` for model and pricing definitions, which is embedded at compile time. This made it impossible to use non-standard Bedrock-accessible models (e.g., GLM Flash via `zai.glm-4.7-flash`) without recompiling the binary or modifying the source config. #### Solution Introduce a `BEDROCK_CONFIG_PATH` environment variable that lets users point to an external YAML file to override the built-in Bedrock provider config. When the variable is unset, the existing embedded `config.yml` is used unchanged (fully backward-compatible). When set, the specified file is read at startup instead. Key changes: - `backend/pkg/config/config.go` — added `BedrockConfig string` field mapped to `BEDROCK_CONFIG_PATH` - `backend/pkg/providers/bedrock/bedrock.go` — `DefaultProviderConfig()` now accepts `*config.Config` and branches on `BedrockConfig` to call either `configFS.ReadFile` (embedded) or `os.ReadFile` (external path) - `backend/pkg/providers/providers.go` and `backend/cmd/ctester/main.go` — updated callers to pass `cfg` to `DefaultProviderConfig` - `docker-compose.yml` — propagates `BEDROCK_CONFIG_PATH` env var into the container and mounts `PENTAGI_BEDROCK_CONFIG_PATH` (defaults to `./glm_flash_bedrock.yml`) at `/opt/pentagi/conf/bedrock.provider.yml` - `glm_flash_bedrock.yml` — new example config for the GLM 4.7 Flash model (`zai.glm-4.7-flash`) accessible via Bedrock, with per-agent tuned parameters and pricing - `.env.example` and `README.md` — documented the new variable Closes # ### Type of Change <!-- Mark with an `x` all options that apply --> - [ ] 🐛 Bug fix (non-breaking change which fixes an issue) - [x] 🚀 New feature (non-breaking change which adds functionality) - [ ] 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected) - [x] 📚 Documentation update - [x] 🔧 Configuration change - [ ] 🧪 Test update - [ ] 🛡️ Security update ### Areas Affected <!-- Mark with an `x` all components that are affected --> - [ ] Core Services (Frontend UI/Backend API) - [ ] AI Agents (Researcher/Developer/Executor) - [ ] Security Tools Integration - [ ] Memory System (Vector Store/Knowledge Base) - [ ] Monitoring Stack (Grafana/OpenTelemetry) - [ ] Analytics Platform (Langfuse) - [x] External Integrations (LLM/Search APIs) - [x] Documentation - [x] Infrastructure/DevOps ### Testing and Verification #### Test Configuration ```yaml PentAGI Version: latest (main + this branch) Docker Version: 27.x Host OS: macOS / Linux LLM Provider: AWS Bedrock (GLM 4.7 Flash via zai.glm-4.7-flash) Enabled Features: none ``` #### Test Steps 1. Copy `.env.example` to `.env` and set `BEDROCK_CONFIG_PATH=./glm_flash_bedrock.yml` along with valid Bedrock credentials (`BEDROCK_REGION`, `BEDROCK_ACCESS_KEY_ID`, `BEDROCK_SECRET_ACCESS_KEY`) 2. Run `docker compose up -d` (or `go run ./cmd/pentagi` from `backend/`) 3. Confirm the Bedrock provider initializes without error and that `zai.glm-4.7-flash` is used for agent calls 4. Remove `BEDROCK_CONFIG_PATH` and restart — confirm the built-in default config is loaded as before #### Test Results Provider initializes successfully with the custom config; falls back cleanly to the embedded config when `BEDROCK_CONFIG_PATH` is unset. ### Security Considerations The file path is read at server startup only, using `os.ReadFile` with the path supplied by the operator via environment variable. No user-controlled input influences the path at runtime. No new network endpoints or permissions introduced. ### Performance Impact Negligible — config file is read once at startup. No change to request-path code. ### Documentation Updates - [x] README.md updates - [ ] API documentation updates - [x] Configuration documentation updates - [ ] GraphQL schema updates - [ ] Other: ### Deployment Notes **New environment variable** (optional, backward-compatible): | Variable | Default | Description | |---|---|---| | `BEDROCK_CONFIG_PATH` | _(empty — uses built-in config)_ | Absolute or relative path to a YAML file that overrides the embedded Bedrock provider model/pricing config | **Docker Compose**: If using a custom config file, set `PENTAGI_BEDROCK_CONFIG_PATH` to the host path of your YAML file. The compose file mounts it to `/opt/pentagi/conf/bedrock.provider.yml` and sets `BEDROCK_CONFIG_PATH` accordingly. A ready-made example for GLM Flash (`glm_flash_bedrock.yml`) is included in the repo root. No database migrations or breaking changes required. ### Checklist #### Code Quality - [x] My code follows the project's coding standards - [x] I have added/updated necessary documentation - [ ] I have added tests to cover my changes - [x] All new and existing tests pass - [x] I have run `go fmt` and `go vet` (for Go code) - [ ] I have run `npm run lint` (for TypeScript/JavaScript code) #### Security - [x] I have considered security implications - [x] Changes maintain or improve the security model - [x] Sensitive information has been properly handled #### Compatibility - [x] Changes are backward compatible - [ ] Breaking changes are clearly marked and documented - [x] Dependencies are properly updated #### Documentation - [x] Documentation is clear and complete - [x] Comments are added for non-obvious code - [ ] API changes are documented ### Additional Notes The `glm_flash_bedrock.yml` included in the repo root serves as both a working config for the GLM 4.7 Flash model and a reference template for users who want to use any other Bedrock-accessible model not covered by the built-in defaults. The YAML structure mirrors the existing embedded `config.yml` format. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-06-06 22:09:54 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#255
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?