Edit an existing Cluster

Change Request Management for Cluster Edits in Scoutflo

The Change Request Management feature for cluster edits allows users to modify existing clusters, commit changes, and raise change requests for review and approval. This structured approach ensures that all modifications are tracked and managed efficiently while incorporating security checks to maintain infra security and best practices.

• Streamlined Editing: Easily edit cluster configurations without directly affecting the main infrastructure.

• Version Control: Utilize branches to manage changes and ensure stability in your deployments.

• Automated Security Scans: Automatically perform security scans on Terraform files using Trivy to identify vulnerabilities and misconfigurations.

• Multiple Commits: Users can commit changes multiple times on a raised CR that is yet to be merged, allowing for a consolidated review of all changes before final deployment.

Step-by-Step Walkthrough

Step 1: Accessing the Change Request Feature for Clusters

1. Go to 'My Clusters':

   • Start on the My Clusters screen where all your deployed clusters are displayed. This is your central hub for managing clusters.

2. Select a Cluster:

   • Locate the cluster you wish to edit. You can either click on the Actions button at the right corner of each cluster in the list or navigate to the cluster post-deploy screen by clicking on the specific cluster.

   • Click on the Edit button that appears in the top right corner of the screen.

3. Redirected to Edit Cluster Screen:

   • After clicking the Edit button, you will be redirected to the Edit Cluster screen where you can view and modify all configuration files used to create this cluster.

Step 2: Editing Cluster Configuration Files

1. Viewing Configuration Files:

   • In the Edit Cluster screen, you will see all Terraform configuration files associated with your cluster. These files define how your cluster is set up and managed.

2. Editing Files:

   • Click on any file you want to modify. Initially, you will be in Read-only mode, which prevents any modifications.

   • To enable editing, click on the Edit button located at the top right corner next to ‘Compare Diff’. This action switches you into Edit mode, allowing you to modify the file contents.

3. Auto-Save Feature:

   • As you make changes, they are automatically saved every time you add or remove content. You can switch between files without losing any entered data.

   • If you click on ‘Compare Diff’ while editing, your progress will still be auto-saved.

4. Undoing Changes:

   • If you make a mistake during editing, use the 'Reset' button to undo recent changes.

5. Resetting Changes:

   • A “Reset” icon is available beside the 'Edit' button. Clicking this icon opens a confirmation modal warning that all progress will be lost if confirmed. If you proceed, it will reset all changes and revert to the default states of all files.

6. Toast Notifications:

   • After making changes, a toast notification will confirm that your changes have been saved successfully (e.g., “Your changes are saved successfully.”).

Step 3: Raising a Change Request

1. Raise Change Request Button:

   • Once you have made and saved your changes, click on the Raise Change Request button.

   • If no changes have been made when this button is clicked, an error toast will inform you that changes are required before raising a CR.

2. Filling Required Fields:

   • The Raise Change Request button will remain inactive until you fill in both the ‘Branch Name’ and ‘Commit Message’, which are mandatory fields for raising a CR.

   • After filling in these details, form validation checks ensure compliance with GitHub rules before submission.

3. Submitting Your Change Request:

   • When you click on the Raise Change Request button, a loader appears while your request is being processed.

   • If successful, the modal closes without retaining any filled data, and a toast notification confirms that your CR has been created.

   • In case of failure while raising the CR, an error toast is displayed, allowing you to make necessary adjustments and retry.

4. Redirection After Success:

   • Upon successful submission of a CR, users are redirected to the CR screen where they can view details of their request.

Or You can commit again to an existing unmerged CR.

Step 4: Workflow Processes After Raising a CR

Once a change request is raised with modifications:

Workflow 1: Initial Change Request Workflow

This workflow is triggered automatically as soon as you raise a change request (CR) with modifications to the cluster configuration files. The steps involved are as follows:

1. Setup Pull Request:

   • A pull request (PR) is created in your GitHub repository. This PR will include all changes made in the raised CR, allowing team members to review the proposed modifications before they are merged into the main branch.

2. Sync .tfstate:

   • The system fetches the latest Terraform state file (.tfstate), which contains information about the current infrastructure resources managed by Terraform. This step ensures that any changes you are proposing are based on the most up-to-date state of your cluster.

3. Initializing Terraform:

   • The command terraform init is executed to initialize the working directory containing your Terraform configuration files. This step sets up the necessary backend and prepares Terraform to execute further commands.

4. Terraform Plan:

   • The command terraform plan runs to create an execution plan. This plan outlines what actions Terraform will take to apply your changes, showing you a preview of what will happen if you proceed with applying these changes.

5. Security Scans:

   • An automated security scan is conducted using Trivy on your Terraform files. This scan identifies any misconfigurations or security vulnerabilities that may exist in your proposed changes, providing an additional layer of assurance before applying updates.

6. Finalize Edit:

   • The status of the workflow is updated in Scoutflo’s database based on the outcomes of the previous steps. This ensures that all progress is tracked and recorded accurately.

7. Cleaning Up:

   • After completing all steps, any temporary data related to this workflow is cleaned up from runtime storage, ensuring that no unnecessary data remains and that system resources are efficiently managed.

Monitoring Workflow 1 Progress

• After this workflow completes, you can view an overview of each step's status, including any errors encountered during execution.

• You will also have access to a Code Diff section, which displays the exact differences between your current configuration and what was changed in this commit.

• The Scans section provides a comprehensive list of all vulnerabilities identified during the Trivy scan, allowing you to assess whether any issues need addressing before proceeding.

Step 5: Reviewing Changes Before Applying

1. Reviewing Scans and Code Diff:

   • Carefully review both the scan results and code diff information provided after completing the initial workflow.

   • Assess whether any identified issues need addressing before proceeding with applying changes.

2. Applying Changes:

   • If satisfied with your review, look for an ‘Apply’ call-to-action (CTA) button located in the Action menu at the top right corner of the screen.

3. Triggering Terraform Apply Workflow:

   • Clicking ‘Apply’ initiates a second workflow that executes terraform apply, applying all approved changes to your cluster configuration.

Workflow 2: Applying Changes Workflow

Once you have reviewed the initial workflow results and decided to apply your changes, a second workflow begins when you click the ‘Apply’ button. This workflow includes additional steps:

1. Setup Pull Request:

   • Similar to Workflow 1, a pull request is set up again if there are new changes since the last workflow was initiated.

2. Sync .tfstate:

   • The latest .tfstate file is fetched again to ensure that all actions are based on the most current state of your infrastructure.

3. Initializing Terraform:

   • The terraform init command runs again to prepare for applying changes, ensuring that everything is set up correctly.

4. Terraform Plan:

   • A new terraform plan command is executed to create an updated execution plan based on any new changes made since the first workflow.

5. Security Scans:

   • Another round of security scans using Trivy occurs to verify that no new vulnerabilities have been introduced since your last review.

6. Terraform Apply:

   • The command terraform apply runs to apply all approved changes to your cluster configuration. This step updates your infrastructure according to the specifications defined in your Terraform files.

7. Finalize Edit:

   • Similar to Workflow 1, this step updates the status in Scoutflo’s database based on whether the apply action was successful or if any issues were encountered during execution.

8. Cleaning Up:

   • Finally, any temporary data related to this workflow is cleaned up from runtime storage, ensuring efficient resource management.

Conclusion

The Change Request Management feature for cluster edits in Scoutflo enhances collaboration while ensuring that modifications are systematically reviewed and approved before application deployment. By understanding these two workflows—initial change request processing and applying changes—you can effectively manage cluster edits within Scoutflo's Change Request Management feature. Each step is designed to ensure thorough validation and security checks before making any modifications to your infrastructure, allowing for safer and more reliable deployments.