-
Notifications
You must be signed in to change notification settings - Fork 256
Vision
The ACK vision is a longer term (12-18 month) plan that outlines our directional thinking for the project. The topics explored in the plan are derived from the previous years' plan, adding items that come from community requests on GitHub, #provider-aws Slack channel and face-to-face discussions.
This vision is not designed to be static, or to directly set the priorities for the ACK core maintainers. We plan on adding, removing and/or updating items throughout the year to better reflect our image of the project. Every plan on the document is meant to serve as inspiration for an exploration, which may mean that we decide not to continue with the implementation.
We actively encourage discussion and contributions from the open-source community! Please reach out if you would like to help.
Plan Status Legend
| Status | Description |
|---|---|
| ⚪ Not Started | No work has begun planning or implementing the plan |
| 🟠 In Planning | Planning has started, but not yet been finalised |
| 🟡 Planned | A plan for the work has been produced, but no implementation has begun |
| 🟢 In Progress | Implementation on the plan has started |
| 🔵 To be Released | Implementation on the plan has been completed but has not been released |
| 🟣 Finished | Implementation on the plan has completed and has been released |
| 🔴 Cancelled | Planning has been indefinitely paused or will not be started |
Status: 🟢 In Progress
ACK plans to continue to create new service controllers based on the demand we see from our users. As part of this plan, we will continue to expand the features of the common code-generator and runtime packages to abstract away common AWS API patterns, decreasing the amount of manual code that needs to be written by maintainers. +1'ing controller issues in the community project is a helpful signal for controller prioritization.
Status: 🟢 In Progress
ACK plans to graduate all started service controllers through to the General Availability (GA) maintenance phase. The ACK core maintainers will work with the maintainers of every service controller repository to ensure they're in a production-ready state and have been tested up to the standard required for GA.
Status: ⚪ Not Started
The ACK code-generator system helps decouple the complexity of the AWS APIs from the higher level abstractions of an "AWS resource" - splitting it into a declarative model with the appropriate CRUD operations. We plan to refactor ACK, to remove the hard dependency on our K8s CRDs, making our generated code agnostic to the underlying system. This would allow other declarative systems to use the ACK resources by importing our common runtime and generating their own clients.
Status: 🟠 In Planning
ACK plans to integrate more closely with the EKS service to provide lifecycle management through directly EKS APIs. This management system will make it easier for EKS customers to install and manage the ACK controllers in their clusters without needing to manage the Helm charts directly.
Status: ⚪ Not Started
Backstage offers a centralized software catalog for microservice teams to manage their infrastructure as code manifests. ACK plans to contribute by submitting either a Backstage plugin or by adding manifests to the community catalog.
Status: 🟢 In Progress
The emergence of GitOps as a standard within K8s for deploying infrastructure as code. The ACK maintainer team plan to advocate for the adoption and growth of GitOps.
Status: 🟢 In Progress
The ACK integration testing framework was designed at a time where there were significantly fewer controllers, and those that did exist were far simpler. As the logic in our controllers has grown, the testing framework has not adapted to support this complexity, hindering our coverage of new features. ACK plans to update the testing framework to support the new common features, such as references field exports and adoption.
Status: ⚪ Not Started
ACK plans to support a stronger story for controller lifecycle management in any supported environment. We plan on testing against a larger range of inputs - such as architecture, cluster provider and cluster version. We also plan on implementing the changes necessary for multi-version support and documenting the upgrade plan for cluster operators.