Files

anthonyrawlins 8d9b62daf3 Phase 2: Implement Execution Environment Abstraction (v0.3.0)

This commit implements Phase 2 of the CHORUS Task Execution Engine development plan,
providing a comprehensive execution environment abstraction layer with Docker
container sandboxing support.

## New Features

### Core Sandbox Interface
- Comprehensive ExecutionSandbox interface with isolated task execution
- Support for command execution, file I/O, environment management
- Resource usage monitoring and sandbox lifecycle management
- Standardized error handling with SandboxError types and categories

### Docker Container Sandbox Implementation
- Full Docker API integration with secure container creation
- Transparent repository mounting with configurable read/write access
- Advanced security policies with capability dropping and privilege controls
- Comprehensive resource limits (CPU, memory, disk, processes, file handles)
- Support for tmpfs mounts, masked paths, and read-only bind mounts
- Container lifecycle management with proper cleanup and health monitoring

### Security & Resource Management
- Configurable security policies with SELinux, AppArmor, and Seccomp support
- Fine-grained capability management with secure defaults
- Network isolation options with configurable DNS and proxy settings
- Resource monitoring with real-time CPU, memory, and network usage tracking
- Comprehensive ulimits configuration for process and file handle limits

### Repository Integration
- Seamless repository mounting from local paths to container workspaces
- Git configuration support with user credentials and global settings
- File inclusion/exclusion patterns for selective repository access
- Configurable permissions and ownership for mounted repositories

### Testing Infrastructure
- Comprehensive test suite with 60+ test cases covering all functionality
- Docker integration tests with Alpine Linux containers (skipped in short mode)
- Mock sandbox implementation for unit testing without Docker dependencies
- Security policy validation tests with read-only filesystem enforcement
- Resource usage monitoring and cleanup verification tests

## Technical Details

### Dependencies Added
- github.com/docker/docker v28.4.0+incompatible - Docker API client
- github.com/docker/go-connections v0.6.0 - Docker connection utilities
- github.com/docker/go-units v0.5.0 - Docker units and formatting
- Associated Docker API dependencies for complete container management

### Architecture
- Interface-driven design enabling multiple sandbox implementations
- Comprehensive configuration structures for all sandbox aspects
- Resource usage tracking with detailed metrics collection
- Error handling with retryable error classification
- Proper cleanup and resource management throughout sandbox lifecycle

### Compatibility
- Maintains backward compatibility with existing CHORUS architecture
- Designed for future integration with Phase 3 Core Task Execution Engine
- Extensible design supporting additional sandbox implementations (VM, process)

This Phase 2 implementation provides the foundation for secure, isolated task
execution that will be integrated with the AI model providers from Phase 1
in the upcoming Phase 3 development.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-09-25 14:28:08 +10:00

7.3 KiB

Raw Blame History

Release Process

Create a `Version Release` issue

Create a Version Release issue to track the release process.

Semantic Convention Generation

New versions of the OpenTelemetry Semantic Conventions mean new versions of the semconv package need to be generated. The semconv-generate make target is used for this.

Set the TAG environment variable to the semantic convention tag you want to generate.
Run the make semconv-generate ... target from this repository.

For example,

export TAG="v1.30.0" # Change to the release version you are generating.
make semconv-generate # Uses the exported TAG.

This should create a new sub-package of semconv. Ensure things look correct before submitting a pull request to include the addition.

Breaking changes validation

You can run make gorelease that runs gorelease to ensure that there are no unwanted changes done in the public API.

You can check/report problems with gorelease here.

Verify changes for contrib repository

If the changes in the main repository are going to affect the contrib repository, it is important to verify that the changes are compatible with the contrib repository.

Follow the steps in the contrib repository to verify OTel changes.

Pre-Release

First, decide which module sets will be released and update their versions in versions.yaml. Commit this change to a new branch.

Update go.mod for submodules to depend on the new release which will happen in the next step.

Run the prerelease make target. It creates a branch prerelease_<module set>_<new tag> that will contain all release changes.
```
make prerelease MODSET=<module set>
```
Verify the changes.
```
git diff ...prerelease_<module set>_<new tag>
```
This should have changed the version for all modules to be <new tag>. If these changes look correct, merge them into your pre-release branch:
```
git merge prerelease_<module set>_<new tag>
```
Update the Changelog.
- Make sure all relevant changes for this release are included and are in language that non-contributors to the project can understand. To verify this, you can look directly at the commits since the <last tag>.
```
git --no-pager log --pretty=oneline "<last tag>..HEAD"
```
- Move all the Unreleased changes into a new section following the title scheme ([<new tag>] - <date of release>).
- Make sure the new section is under the comment for released section, like , so it is protected from being overwritten in the future.
- Update all the appropriate links at the bottom.
Push the changes to upstream and create a Pull Request on GitHub. Be sure to include the curated changes from the Changelog in the description.

Tag

Once the Pull Request with all the version changes has been approved and merged it is time to tag the merged commit.

IMPORTANT: It is critical you use the same tag that you used in the Pre-Release step! Failure to do so will leave things in a broken state. As long as you do not change versions.yaml between pre-release and this step, things should be fine.

IMPORTANT: There is currently no way to remove an incorrectly tagged version of a Go module. It is critical you make sure the version you push upstream is correct. Failure to do so will lead to minor emergencies and tough to work around.

For each module set that will be released, run the add-tags make target using the <commit-hash> of the commit on the main branch for the merged Pull Request.
```
make add-tags MODSET=<module set> COMMIT=<commit hash>
```
It should only be necessary to provide an explicit COMMIT value if the current HEAD of your working directory is not the correct commit.
Push tags to the upstream remote (not your fork: github.com/open-telemetry/opentelemetry-go.git). Make sure you push all sub-modules as well.
```
git push upstream <new tag>
git push upstream <submodules-path/new tag>
...
```

Release

Finally create a Release for the new <new tag> on GitHub. The release body should include all the release notes from the Changelog for this release.

Sign the Release Artifact

To ensure we comply with CNCF best practices, we need to sign the release artifact. The tarball attached to the GitHub release needs to be signed with your GPG key.

Follow these steps to sign the release artifact and upload it to GitHub. You can use this script to verify the contents of the tarball before signing it.

Be sure to use the correct GPG key when signing the release artifact.

gpg --local-user <key-id> --armor --detach-sign opentelemetry-go-<version>.tar.gz

You can verify the signature with:

gpg --verify opentelemetry-go-<version>.tar.gz.asc opentelemetry-go-<version>.tar.gz

Post-Release

Contrib Repository

Once verified be sure to make a release for the contrib repository that uses this release.

Website Documentation

Update the Go instrumentation documentation in the OpenTelemetry website under content/en/docs/languages/go. Importantly, bump any package versions referenced to be the latest one you just released and ensure all code examples still compile and are accurate.

Close the milestone

Once a release is made, ensure all issues that were fixed and PRs that were merged as part of this release are added to the corresponding milestone. This helps track what changes were included in each release.

To find issues that haven't been included in a milestone, use this GitHub search query
To find merged PRs that haven't been included in a milestone, use this GitHub search query.

Once all related issues and PRs have been added to the milestone, close the milestone.

Demo Repository

Bump the dependencies in the following Go services:

Close the `Version Release` issue

Once the todo list in the Version Release issue is complete, close the issue.

7.3 KiB Raw Blame History