lfg2025/archy
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 33 Wiki Activity

[ARCH-001] Refactor Parmanode Compatibility Layer #1

New Issue
Closed
opened 2026-03-25 15:24:31 +00:00 by dimo · 2 comments
dimo commented 2026-03-25 15:24:31 +00:00
Copy Link

Problem

The Archipelago codebase contains a "Frankenstein" architecture where Parmanode compatibility is awkwardly grafted onto the system. This creates several issues:

  1. Tight coupling to Parmanode's installation patterns
  2. Inconsistent configuration management (mixing manual file edits with manifest-driven approach)
  3. Hardcoded paths that don't respect Podman's container isolation
  4. No clear separation between Parmanode-specific logic and core orchestration
  5. Makes it difficult to support other installation methods or alternative packaging

Impact:

  • Reduces maintainability and increases technical debt
  • Limits flexibility for future installation methods
  • Violates single responsibility principle
  • Makes testing and validation more difficult

Proposed Solution

Implement a clean abstraction layer that separates compatibility concerns:

  1. Create a CompatibilityAdapter trait/interface that defines the contract for installation methods
  2. Implement a ParmanodeAdapter that translates Parmanode patterns to Archipelago's manifest format
  3. Refactor all hardcoded Parmanode-specific code to use the adapter
  4. Create a NativeAdapter for pure Archipelago installations
  5. Add configuration to select the appropriate adapter at runtime

Benefits:

  • Loose coupling to specific installation methods
  • Easy to add new installation adapters (Docker Compose, K8s, etc.)
  • Cleaner, more testable code
  • Better separation of concerns

Affected areas:

  • core/manifest/ - Remove Parmanode-specific assumptions
  • core/archipelago/ - Use adapter for installation detection
  • core/security/ - Abstract security model through adapter
  • Configuration files - Add adapter selection
  • Documentation - Update to reflect multi-adapter architecture

Acceptance Criteria

  • CompatibilityAdapter trait defined with clear interface
  • ParmanodeAdapter implements trait and passes all existing tests
  • NativeAdapter implemented for pure Archipelago installations
  • All hardcoded Parmanode paths/assumptions removed from core code
  • Configuration option to select adapter at runtime
  • Documentation updated with adapter architecture
  • All existing tests pass
  • New tests added for adapter pattern

Priority: High
Type: Architecture/Refactor
Estimated effort: 2-3 weeks

## Problem The Archipelago codebase contains a "Frankenstein" architecture where Parmanode compatibility is awkwardly grafted onto the system. This creates several issues: 1. Tight coupling to Parmanode's installation patterns 2. Inconsistent configuration management (mixing manual file edits with manifest-driven approach) 3. Hardcoded paths that don't respect Podman's container isolation 4. No clear separation between Parmanode-specific logic and core orchestration 5. Makes it difficult to support other installation methods or alternative packaging **Impact:** - Reduces maintainability and increases technical debt - Limits flexibility for future installation methods - Violates single responsibility principle - Makes testing and validation more difficult ## Proposed Solution Implement a clean abstraction layer that separates compatibility concerns: 1. Create a `CompatibilityAdapter` trait/interface that defines the contract for installation methods 2. Implement a `ParmanodeAdapter` that translates Parmanode patterns to Archipelago's manifest format 3. Refactor all hardcoded Parmanode-specific code to use the adapter 4. Create a `NativeAdapter` for pure Archipelago installations 5. Add configuration to select the appropriate adapter at runtime **Benefits:** - Loose coupling to specific installation methods - Easy to add new installation adapters (Docker Compose, K8s, etc.) - Cleaner, more testable code - Better separation of concerns **Affected areas:** - `core/manifest/` - Remove Parmanode-specific assumptions - `core/archipelago/` - Use adapter for installation detection - `core/security/` - Abstract security model through adapter - Configuration files - Add adapter selection - Documentation - Update to reflect multi-adapter architecture ## Acceptance Criteria - [ ] CompatibilityAdapter trait defined with clear interface - [ ] ParmanodeAdapter implements trait and passes all existing tests - [ ] NativeAdapter implemented for pure Archipelago installations - [ ] All hardcoded Parmanode paths/assumptions removed from core code - [ ] Configuration option to select adapter at runtime - [ ] Documentation updated with adapter architecture - [ ] All existing tests pass - [ ] New tests added for adapter pattern **Priority:** High **Type:** Architecture/Refactor **Estimated effort:** 2-3 weeks
dimo commented 2026-03-25 21:03:24 +00:00
Author
Copy Link

Codebase Analysis Update (2026-03-25)

This issue has been partially addressed - clean adapter pattern exists but needs verification of completeness:

✅ Completed:

Adapter Pattern Implementation:
core/parmanode/
├── lib.rs - Module exports (ParmanodeScriptRunner, ParmanodeConverter)
├── script_runner.rs - Executes Parmanode scripts in isolated containers
└── converter.rs - Converts Parmanode modules to App Manifests

ParmanodeScriptRunner Features:

  • Scripts run in isolated Alpine containers (via Podman)
  • Detects Parmanode script patterns (.sh files with parmanode/bitcoin/lightning/electrs)
  • Creates wrapper scripts for container execution
  • Attempts to convert modules to app manifests
  • Clean separation from core orchestration logic

ParmanodeConverter Features:

  • Converts Parmanode module directories to App Manifests
  • Infers app details from script content (Bitcoin Core, LND, Core Lightning, Electrs)
  • Generates YAML manifests with security policies (readonly_root, network_policy: isolated)
  • Falls back to generic Alpine 3.19 image for unknown modules

🔶 Remaining Work (Needs Verification):

From Issue Requirements:

  • CompatibilityAdapter trait/interface - Not clearly defined
  • ParmanodeAdapter implementation - Partial (script_runner.rs exists but not as trait impl)
  • NativeAdapter for pure Archipelago - Not implemented
  • Refactor hardcoded Parmanode-specific code - Still some hardcoded paths (/tmp/parmanode-*.sh)
  • Use adapter for installation detection in core/archipelago/ - Needs verification
  • Abstract security model through adapter - Not clearly implemented
  • Configuration to select adapter at runtime - Not implemented
  • Remove Parmanode assumptions from core/manifest/ - Needs verification
  • Remove Parmanode assumptions from core/security/ - Needs verification

Assessment:

The codebase has a good foundation with clean module separation and adapter-like behavior. However, this is not yet a complete abstraction layer with:

  • Formal trait/interface definitions
  • Multiple adapter implementations (Parmanode, Native, Docker Compose, etc.)
  • Runtime adapter selection via configuration
  • Full removal of Parmanode assumptions from core modules

Recommendation: This issue should remain OPEN. The refactoring is partially complete but needs:

  1. Define CompatibilityAdapter trait with required methods
  2. Implement ParmanodeAdapter trait implementation
  3. Add NativeAdapter for pure Archipelago installations
  4. Add configuration for runtime adapter selection
  5. Audit core/archipelago/ and core/security/ for Parmanode assumptions
  6. Update documentation to reflect multi-adapter architecture

Analysis by Subagent 1 - Codebase Review 2026-03-25

## Codebase Analysis Update (2026-03-25) This issue has been **partially addressed** - clean adapter pattern exists but needs verification of completeness: ### ✅ Completed: **Adapter Pattern Implementation:** core/parmanode/ ├── lib.rs - Module exports (ParmanodeScriptRunner, ParmanodeConverter) ├── script_runner.rs - Executes Parmanode scripts in isolated containers └── converter.rs - Converts Parmanode modules to App Manifests **ParmanodeScriptRunner Features:** - Scripts run in isolated Alpine containers (via Podman) - Detects Parmanode script patterns (.sh files with parmanode/bitcoin/lightning/electrs) - Creates wrapper scripts for container execution - Attempts to convert modules to app manifests - Clean separation from core orchestration logic **ParmanodeConverter Features:** - Converts Parmanode module directories to App Manifests - Infers app details from script content (Bitcoin Core, LND, Core Lightning, Electrs) - Generates YAML manifests with security policies (readonly_root, network_policy: isolated) - Falls back to generic Alpine 3.19 image for unknown modules ### 🔶 Remaining Work (Needs Verification): **From Issue Requirements:** - [ ] CompatibilityAdapter trait/interface - Not clearly defined - [ ] ParmanodeAdapter implementation - Partial (script_runner.rs exists but not as trait impl) - [ ] NativeAdapter for pure Archipelago - Not implemented - [ ] Refactor hardcoded Parmanode-specific code - Still some hardcoded paths (/tmp/parmanode-*.sh) - [ ] Use adapter for installation detection in core/archipelago/ - Needs verification - [ ] Abstract security model through adapter - Not clearly implemented - [ ] Configuration to select adapter at runtime - Not implemented - [ ] Remove Parmanode assumptions from core/manifest/ - Needs verification - [ ] Remove Parmanode assumptions from core/security/ - Needs verification ### Assessment: The codebase has a **good foundation** with clean module separation and adapter-like behavior. However, this is **not yet a complete abstraction layer** with: - Formal trait/interface definitions - Multiple adapter implementations (Parmanode, Native, Docker Compose, etc.) - Runtime adapter selection via configuration - Full removal of Parmanode assumptions from core modules **Recommendation**: This issue should remain **OPEN**. The refactoring is partially complete but needs: 1. Define CompatibilityAdapter trait with required methods 2. Implement ParmanodeAdapter trait implementation 3. Add NativeAdapter for pure Archipelago installations 4. Add configuration for runtime adapter selection 5. Audit core/archipelago/ and core/security/ for Parmanode assumptions 6. Update documentation to reflect multi-adapter architecture --- _Analysis by Subagent 1 - Codebase Review 2026-03-25_
lfg2025 commented 2026-03-26 15:33:40 +00:00
Owner
Copy Link

closed and removed dead code

closed and removed dead code
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lfg2025
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lfg2025/archy#1
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?