-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branch-based Planner for TF-controller #527
Comments
@chanwit I'll review this in a couple days, moved it to the top of the new column on our board. |
ping @JamWils |
@yiannistri, can you review this and give your input? |
The proposal looks reasonable to me. Some clarifying questions:
|
Thank you @yiannistri all are very good questions!
|
I'll reflect your questions back into the proposal. Thank you again @yiannistri |
@foot and @bigkevmcd is there an opportunity to leverage GitOps Sets here? Maybe I am wrong, but I guess the missing piece outside of that is to be able to post back to the github issue in question. |
It sounds reasonable, and I think it's a good feature. Few notes I would expect as a user:
Questions:
|
Thank you @yitsushi
Input variables could be defined in many ways,
It's following the behavior you would expect from running Terraform binary. If the input has the default value, it goes with that value. If not, and mandatory, the Terraform binary would tell the runner to exit with an error, and the reconciliation would retry. |
This behavior has not been defined yet. We could refine them together. |
A draft of the component diagram: graph LR
GH[GitHub PR] <-- retrieve --> PRP
subgraph "Planner System"
PRP[PR Poller]
MC[Informer]
end
MC -- talk to --> K8s[K8s API Server]
|
Hi all, some questions from a newcomer here. If we've answered these questions elsewhere, let's sync quickly offline (ie don't feel obligated to rehash material)
|
FWIW I quickly ran the questions above past @yiannistri before posting |
@yitsushi reviewed the user stories posted above to see what's done, and noted that they all roughly suggest the same thing. As the user stories are all describing a full workflow, they'll all be done at once when the MVP is ready to release. |
If my branch has a change to use a secret for inputs, how does the secret get into the cluster? |
That secret must be available in the cluster first as a pre-condition before the planning process kicks off. |
Updated workflow as we chose to implement the polling mechanism instead of webhooks.
|
sequenceDiagram
participant P as Poller
participant GH as GitHub PR
participant I as Informer
participant T as Terraform CR
participant GR as GitRepository
participant SC as Source Controller
P->>GH: Read PR information
P->>T: Create Terraform CR (planOnly=true)
P->>GR: Create GitRepository (points to PR branch)
P->>I: Associate PR with GitRepository and Terraform CR
P->>GH: Read comments (!restart or !replan)
P->>T: Initiate "force restart" of the plan
SC-->>T: Detects changes, trigger plan
I->>T: Watch for plan generation
I-->>GH: Show Terraform plan as comment
P->>GH: Read merged status
P->>T: Deletes Terraform resource
P->>GR: Deletes GitRepository
|
If this was me, I'd design to work on either polled comments or webhook notifications. The simplest to get going in many enterprises will be polled, but, there definitely advantages to hook-driven (fewer API calls, faster turnaround). |
Right, it shouldn't be either/or. Design for adding webhooks later. |
Yep, the first couple of MVPs will go with polling. We'll take a look at the webhook approach again after that. |
Overview
The Branch-based Planner (aka Terraform plan result in PR) is a feature of the Terraform Controller that enables users to establish a link between a Pull Request and a Terraform CR (Customer Resource) object, which also referred to as a Terraform Plan Object. This feature allows users to create a new branch, which is then used to create a temporary
GitRepository
object. The Terraform Plan Object is derived from the original Terraform CR object and is pointed to the same Git repository, but on a new branch instead of the main branch of the repository.The system allows users to make changes to the branch in a "plan-only" mode, displaying the plan information as a comment. The new plan is displayed as another comment when changes are made to the branch. Users can also trigger a replan by commenting under the pull request.
Once the user is satisfied with the changes made to the branch, they can merge it to the main branch, after which the new branch's Terraform plan object and GitRepository can be deleted.
The Branch-based Planner system can be extended to support other Git hosting platforms like GitLab, Bitbucket, or Azure DevOps by using their respective webhook mechanisms. The core idea of the Branch-based Planner system remains the same, but the webhook integration would need to be adapted to work with the desired platform. But GitHub is the only platform we would support for the first MVP.
Goals
Objectives
Objective 1
Allow users to make changes to the branch in a "plan-only" mode and display plan information as comments.
Use case
Assuming a scenario where a developer needs to make changes to the infrastructure managed by Terraform, the use case for this objective is to enable the developer to create a new branch, make changes to the configuration files, and generate a plan for the changes made in the new branch. The resulting plan information should be displayed as comments in the corresponding pull request, allowing the developer to review the changes and collaborate with other team members.
Objective 2
Allow users to trigger replans through comments.
Use Case
Assuming a scenario where a developer needs to make further changes to the infrastructure managed by Terraform after a pull request is created, the use case for this objective is to enable the developer to trigger a replan by posting specific comments within the corresponding pull request. The updated plan information should be automatically generated and displayed as comments in the pull request.
Components
GitRepository
.infra.contrib.fluxcd.io/v1alpha2.Terraform
.infra.contrib.fluxcd.io/v1alpha2.Terraform
.Scenarios
Scenario 1
User Stories
The text was updated successfully, but these errors were encountered: