feat: add TSYSDevStack SupportStack MVP prompt and supporting files
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
This commit is contained in:
170
collab/SupportStack/BuildTheStack
Normal file
170
collab/SupportStack/BuildTheStack
Normal file
@@ -0,0 +1,170 @@
|
||||
# TSYSDevStack SupportStack Demo Builder
|
||||
|
||||
## Objective
|
||||
Create an out-of-the-box, localhost-bound only, ephemeral Docker volume-only demonstration version of the SupportStack components documented in the VendorList-SupportStack.md file.
|
||||
|
||||
## MVP Test Run Objective
|
||||
Create a proof of concept with docker-socket-proxy, homepage, and wakaapi components that demonstrate proper homepage integration via Docker Compose labels. This MVP will serve as a validation of the full approach before proceeding with the complete stack implementation.
|
||||
|
||||
## Architecture Requirements
|
||||
- All Docker artifacts must be prefixed with `TSYSDevStack-SupportStack-Demo`
|
||||
- Run exclusively on localhost (localhost binding only)
|
||||
- Ephemeral volumes only (no persistent storage)
|
||||
- Resource limits set for single-user demo capacity
|
||||
- No external network access (localhost bound only)
|
||||
- Components: docker-socket-proxy, portainer, homepage as foundational elements
|
||||
- All artifacts must go into artifacts/SupportStack directory to keep the directory well organized and avoid cluttering the root directory
|
||||
|
||||
## Development Methodology
|
||||
- Strict Test Driven Development (TDD) process
|
||||
- Write test → Execute test → Test fails → Write minimal code to pass test
|
||||
- 75%+ code coverage requirement
|
||||
- 100% test pass requirement
|
||||
- Component-by-component development approach
|
||||
- Complete one component before moving to the next
|
||||
|
||||
## MVP Component Development Sequence (Test Run)
|
||||
1. **MVP**: docker-socket-proxy, homepage, wakaapi (each must fully satisfy Definition of Done before proceeding)
|
||||
- docker-socket-proxy: Enable Docker socket access for homepage integration
|
||||
- homepage: Configure to access Docker socket and discover labeled containers
|
||||
- wakaapi: Integrate with homepage using proper labels
|
||||
- All services must utilize Docker Compose labels to automatically show up in homepage
|
||||
- Implement proper service discovery for homepage integration using gethomepage labels
|
||||
- Ensure all components are properly labeled with homepage integration labels
|
||||
- Implement proper startup ordering using depends_on with health checks
|
||||
|
||||
## Component Completion Validation
|
||||
- Each component must pass health checks for 5 consecutive minutes before moving to the next
|
||||
- All tests must pass with 100% success rate before moving to the next component
|
||||
- Resource utilization must be within specified limits before moving to the next component
|
||||
- Integration tests with previously completed components must pass before moving forward
|
||||
- Homepage must automatically detect and display all services with proper labels
|
||||
|
||||
## Technical Specifications
|
||||
- No Bitnami images allowed
|
||||
- Use official or trusted repository images only
|
||||
- Implement Docker Compose orchestration
|
||||
- Use Docker named volumes for ephemeral storage
|
||||
- Implement proper resource limits in docker-compose.yml: CPU: 0.5-1.0 cores per service, Memory: 128MB-512MB per service (variable based on service type), Disk: 1GB per service for ephemeral volumes
|
||||
- Implement comprehensive health checks for all services with appropriate intervals and timeouts
|
||||
- Implement proper networking (internal only)
|
||||
- All ports bound to localhost (127.0.0.1)
|
||||
- All environment variables must be pre-set in TSYSDevStack-SupportStack-Demo-Settings file (single settings file for simplicity in demo)
|
||||
- All docker compose files (one per component) should be prefixed with: TSYSDevStack-SupportStack-Demo-DockerCompose-
|
||||
- All docker compose files should use environment variables for everything (variables will be set in TSYSDevStack-SupportStack-Demo-Settings file)
|
||||
- Health checks must validate service readiness before proceeding with dependent components
|
||||
- Health check endpoints must be accessible only from internal network
|
||||
- Health check configurations must be parameterized via environment variables
|
||||
- All services must utilize Docker Compose labels to automatically show up in homepage
|
||||
- Implement proper homepage integration labels for automatic service discovery using gethomepage/homepage labels:
|
||||
- Required: homepage.group, homepage.name, homepage.icon
|
||||
- Optional: homepage.href, homepage.description, homepage.widget.type, homepage.widget.url, homepage.widget.key, homepage.widget.fields, homepage.weight
|
||||
- Homepage integration must include proper naming, icons, and status indicators
|
||||
- Use pinned image tags rather than 'latest' for all container images
|
||||
- Run containers as non-root users where possible
|
||||
- Enable read-only filesystems where appropriate
|
||||
- Implement security scanning during build process (for demo, secrets via environment variables are acceptable)
|
||||
- Define network policies for internal communication only
|
||||
- Use depends_on with health checks to ensure proper startup ordering of services
|
||||
|
||||
## Stack Control
|
||||
- All control of the stack should go into a script called TSYSDevStack-SupportStack-Demo-Control.sh
|
||||
- The script should take the following arguments: start/stop/uninstall/update/test
|
||||
- Ensure script is executable and contains error handling
|
||||
|
||||
## Component Definition of Done
|
||||
- All health checks pass consistently for each component
|
||||
- Test suite passes with 100% success rate (unit, integration, e2e)
|
||||
- Code coverage of >75% for each component
|
||||
- Resource limits properly implemented and validated (CPU: 0.5-1.0 cores, Memory: 128MB-512MB, Disk: 1GB per service)
|
||||
- All services properly bound to localhost only
|
||||
- Proper error handling and logging implemented (with retry logic and exponential backoff)
|
||||
- Documentation and configuration files created
|
||||
- Component successfully starts, runs, and stops without manual intervention
|
||||
- Component properly integrates with other components without conflicts
|
||||
- Automated self-recovery mechanisms implemented for common failure scenarios
|
||||
- Performance benchmarks met for single-user demo capacity (apply reasonable defaults based on service type)
|
||||
- Security scans completed and passed (run as non-root, read-only filesystems where appropriate)
|
||||
- No hard-coded values; all configuration via environment variables
|
||||
- All dependencies properly specified and resolved using depends_on with health checks
|
||||
- Component properly labeled with homepage integration labels (homepage.group, homepage.name, homepage.icon, etc.)
|
||||
- Container uses pinned image tags rather than 'latest'
|
||||
|
||||
## Testing Requirements
|
||||
- Unit tests for each component configuration
|
||||
- Integration tests for component interactions
|
||||
- End-to-end tests for the complete stack
|
||||
- Performance tests to validate resource limits
|
||||
- Security tests for localhost binding
|
||||
- Health check tests for all services
|
||||
- Coverage report generation
|
||||
- Continuous test execution during development
|
||||
- Automated test suite execution for each component before moving to the next
|
||||
- End-to-end validation tests after each component integration
|
||||
|
||||
## Error Resolution Strategy
|
||||
- Implement autonomous error detection and resolution
|
||||
- Automatic retry mechanisms for transient failures with exponential backoff (base delay of 5s, max 5 attempts)
|
||||
- Fallback configurations for compatibility issues
|
||||
- Comprehensive logging for debugging
|
||||
- Graceful degradation for optional components
|
||||
- Automated rollback for failed deployments
|
||||
- Self-healing mechanisms for common failure scenarios
|
||||
- Automated restart policies with appropriate backoff strategies
|
||||
- Deadlock detection and resolution mechanisms
|
||||
- Resource exhaustion monitoring and mitigation
|
||||
- Automated cleanup of failed component attempts
|
||||
- Persistent state recovery mechanisms
|
||||
- Fail-safe modes for critical components
|
||||
- Circuit breaker patterns for service dependencies
|
||||
- If unable to resolve an issue after multiple attempts, flag it in collab/SupportStack/HUMANHELP.md and move on
|
||||
- Maintain running status reports in collab/SupportStack/STATUS.md
|
||||
- Use git commit heavily to track progress
|
||||
- Push to remote repository whenever a component is fully working/tested/validated
|
||||
|
||||
## Autonomous Operation Requirements
|
||||
- Project must be capable of running unattended for 1-2 days without manual intervention
|
||||
- All components must implement self-monitoring and self-healing
|
||||
- Automated monitoring of resource usage with alerts if limits exceeded
|
||||
- All failure scenarios must have automated recovery procedures
|
||||
- Consistent state maintenance across all components
|
||||
- Automated cleanup of temporary resources
|
||||
- Comprehensive logging for troubleshooting without human intervention
|
||||
- Built-in validation checks to ensure continued operation
|
||||
- Automatic restart of failed services with appropriate retry logic
|
||||
- Prevention of resource leaks and proper cleanup on shutdown
|
||||
|
||||
## Qwen Optimization
|
||||
- Structured for autonomous execution
|
||||
- Clear task decomposition
|
||||
- Explicit success/failure criteria
|
||||
- Self-contained instructions
|
||||
- Automated validation steps
|
||||
- Progress tracking mechanisms
|
||||
|
||||
## Output Deliverables
|
||||
- Directory structure in artifacts/SupportStack
|
||||
- Environment variables file: TSYSDevStack-SupportStack-Demo-Settings
|
||||
- Control script: TSYSDevStack-SupportStack-Demo-Control.sh (with start/stop/uninstall/update/test arguments)
|
||||
- Docker Compose files prefixed with: TSYSDevStack-SupportStack-Demo-DockerCompose-
|
||||
- Component configuration files
|
||||
- Test suite (unit, integration, e2e)
|
||||
- Coverage reports
|
||||
- Execution logs
|
||||
- Documentation files
|
||||
- Health check scripts and configurations
|
||||
- Component readiness and liveness check definitions
|
||||
- Automated validation scripts for component completion
|
||||
- Monitoring and alerting configurations
|
||||
|
||||
The implementation should work autonomously, handling errors and resolving configuration issues without human intervention while strictly adhering to the TDD process.
|
||||
|
||||
## Production Considerations
|
||||
- For production implementation, additional items will be addressed including:
|
||||
- Enhanced monitoring and observability with centralized logging
|
||||
- Advanced security measures (secrets management, network policies, etc.)
|
||||
- Performance benchmarks and optimization
|
||||
- Configuration management with separation of required vs optional parameters
|
||||
- Advanced documentation (architecture diagrams, troubleshooting guides, etc.)
|
||||
- Production-grade error handling and recovery procedures
|
||||
- All deferred items will be tracked in collab/SupportStack/ProdRoadmap.md
|
||||
Reference in New Issue
Block a user