-
Spike
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
5
-
False
-
-
False
-
rhel-container-tools
-
-
-
RUN 274, RUN 275, RUN 276, RUN 277
Summary: Investigate the feasibility and effort required to implement the BuildKit GRPC API in Podman's API server to unblock customer requests and enable broader Docker Compose compatibility.
Description:
The BuildKit GRPC API (https://github.com/moby/buildkit/tree/master/api) is a modern, feature-rich interface for container image building. Currently, Podman's API server does not expose this API, which leads to several limitations for users, notably:
- Blocked Customer Requests: Important customer requests, such as https://github.com/containers/buildah/issues/4211, which require advanced build capabilities, remain unaddressed.
- Docker Compose v2+ Compatibility: Docker Compose versions 2 and up increasingly rely on the BuildKit API for their build operations. Without this API, Podman users are forced to rely on the legacy build API or face compatibility issues when using newer Docker Compose versions.
Implementing the BuildKit GRPC API in Podman's API server is expected to be a substantial undertaking due to its large scope and the relatively poor documentation available for the API itself. However, successfully integrating this API will significantly enhance Podman's build capabilities, improve its compatibility with modern tooling, and unblock critical user workflows.
This spike is necessary to thoroughly investigate the complexities, design considerations, and overall effort involved in implementing this API.
Investigation Scope:
- API Deep Dive: Conduct an in-depth analysis of the BuildKit GRPC API specification and its various services (e.g., control, solver, worker, session). Understand the core concepts, data structures, and interaction patterns.
- Podman API Server Integration Points: Identify how the BuildKit GRPC API would integrate with Podman's existing API server architecture. This includes:
-
- Mapping BuildKit concepts to Podman's internal build mechanisms (e.g., buildah).
-
- Handling authentication and authorization for the new API endpoints.
-
- Considering the impact on existing Podman API endpoints and potential overlaps.
- Build Engine Compatibility: Determine how Podman's underlying build engine (buildah) can be adapted or extended to fulfill the requirements of the BuildKit GRPC API. This may involve identifying gaps in buildah's current capabilities.
- Documentation and Examples Review: Despite the general poor documentation, identify any existing examples or community resources that could aid in understanding and implementing the API.
- Effort Estimation: Provide a preliminary estimate (e.g., T-shirt size: Small, Medium, Large) for the work required to implement a functional subset or the full BuildKit GRPC API.
- Alternative Approaches: Briefly consider if there are any simpler, incremental approaches to address the unblocked customer requests and Docker Compose compatibility without a full BuildKit GRPC API implementation, and note their pros/cons.
Expected Outcomes:
- A detailed technical assessment of the BuildKit GRPC API and its components.
- A high-level design proposal for integrating the BuildKit GRPC API into Podman's API server.
- Identification of key technical challenges and potential solutions.
- A preliminary estimate of the implementation effort required.
- A clear recommendation on whether to proceed with the implementation, including a justification and suggested next steps (e.g., a new story for implementation).
- links to