Rename tf-controller to tofu-controller

.goreleaser.yml

@@ -1,4 +1,4 @@
-project_name: tf-controller
+project_name: tofu-controller
 
 release:
   prerelease: "true"

DEVELOPMENT.md

@@ -18,7 +18,7 @@ to merge them for you after reviews.
 
 ## Protobuf Setup
 
-TF-controller requires a specific version of Protobuf compiler and its Go plugins.
+Tofu-controller requires a specific version of Protobuf compiler and its Go plugins.
 
 * Protoc: version [3.19.4](https://github.com/protocolbuffers/protobuf/releases/download/v3.19.4/protoc-3.19.4-linux-x86_64.zip)
 * Go plugin: `go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.27.1`
@@ -103,7 +103,7 @@ Tilt will automatically detect code changes which will retrigger a build and red
 Set the name of the container image to be created from the source code. This will be used when building, pushing and referring to the image on YAML files:
 
 ```sh
-export MANAGER_IMG=registry-path/tf-controller
+export MANAGER_IMG=registry-path/tofu-controller
 ```
 
 Build the container image, tagging it as `$MANAGER_IMG:latest`:
@@ -122,7 +122,7 @@ make docker-push
 
 ### Deploying into a cluster
 
-Deploy `tf-controller` into the cluster that is configured in the local kubeconfig file (i.e. `~/.kube/config`):
+Deploy `tofu-controller` into the cluster that is configured in the local kubeconfig file (i.e. `~/.kube/config`):
 
 ```sh
 make deploy
@@ -132,11 +132,11 @@ Running the above will also deploy `source-controller` and its CRDs to the clust
 
 ### Debug
 
-`sudo dlv --listen=:2345 --headless=true --api-version=2 attach $(pgrep tf-controller)`
+`sudo dlv --listen=:2345 --headless=true --api-version=2 attach $(pgrep tofu-controller)`
 
 ## Communications
 
-For realtime communications we use Slack: To join the conversation, simply join the [Weave Users](https://weave-community.slack.com/) Slack workspace and use the [#tf-controller](https://weave-community.slack.com/messages/tf-controller/) channel.
+For realtime communications we use Slack: To join the conversation, simply join the [Weave Users](https://weave-community.slack.com/) Slack workspace and use the [#tofu-controller](https://weave-community.slack.com/messages/tofu-controller/) channel.
 
 To discuss ideas and specifications we use [Github Discussions](https://github.com/flux-iac/tofu-controller/discussions).
 

README.md

@@ -24,7 +24,7 @@ If you have a feature request to share or a bug to report, please file an issue.
 
 To get started check out this [guide](https://flux-iac.github.io/tofu-controller/getting_started/) on how to GitOps your Terraform resources with Tofu Controller and Flux.
 
-Check out the [documentation](https://flux-iac.github.io/tofu-controller/) and [use cases](https://flux-iac.github.io/tofu-controller/use-tf-controller/).
+Check out the [documentation](https://flux-iac.github.io/tofu-controller/) and [use cases](https://flux-iac.github.io/tofu-controller/use-tofu-controller/).
 
 ## Roadmap
 

api/v1alpha2/terraform_types.go

@@ -24,7 +24,6 @@ import (
 	"time"
 	"unicode/utf8"
 
-	"github.com/flux-iac/tofu-controller/api/planid"
 	"github.com/fluxcd/pkg/apis/meta"
 	sourcev1 "github.com/fluxcd/source-controller/api/v1"
 	corev1 "k8s.io/api/core/v1"
@@ -33,10 +32,12 @@ import (
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"k8s.io/apimachinery/pkg/runtime"
 	"k8s.io/apimachinery/pkg/runtime/serializer"
+
+	"github.com/flux-iac/tofu-controller/api/planid"
 )
 
 const (
-	CACertSecretName = "tf-controller.tls"
+	CACertSecretName = "tofu-controller.tls"
 	// RunnerTLSSecretName is the name of the secret containing a TLS cert that will be written to
 	// the namespace in which a terraform runner is created
 	RunnerTLSSecretName     = "terraform-runner.tls"

cmd/manager/main.go

@@ -23,8 +23,6 @@ import (
 	"github.com/flux-iac/tofu-controller/mtls"
 	"github.com/flux-iac/tofu-controller/runner"
 
-	infrav1 "github.com/flux-iac/tofu-controller/api/v1alpha2"
-	"github.com/flux-iac/tofu-controller/controllers"
 	"github.com/fluxcd/pkg/runtime/acl"
 	"github.com/fluxcd/pkg/runtime/client"
 	runtimeCtrl "github.com/fluxcd/pkg/runtime/controller"
@@ -44,6 +42,9 @@ import (
 	"sigs.k8s.io/controller-runtime/pkg/healthz"
 	metricsserver "sigs.k8s.io/controller-runtime/pkg/metrics/server"
 
+	infrav1 "github.com/flux-iac/tofu-controller/api/v1alpha2"
+	"github.com/flux-iac/tofu-controller/controllers"
+
 	// Import all Kubernetes client auth plugins (e.g. Azure, GCP, OIDC, etc.)
 	// to ensure that exec-entrypoint and run can make use of them.
 	_ "k8s.io/client-go/plugin/pkg/client/auth"
@@ -52,7 +53,7 @@ import (
 	//+kubebuilder:scaffold:imports
 )
 
-const controllerName = "tf-controller"
+const controllerName = "tofu-controller"
 
 var (
 	scheme   = runtime.NewScheme()
@@ -183,9 +184,9 @@ func main() {
 	certsReady := make(chan struct{})
 	rotator := &mtls.CertRotator{
 		Ready:                         certsReady,
-		CAName:                        "tf-controller",
-		CAOrganization:                "weaveworks",
-		DNSName:                       "tf-controller",
+		CAName:                        "tofu-controller",
+		CAOrganization:                "flux-iac",
+		DNSName:                       "tofu-controller",
 		CAValidityDuration:            caValidityDuration,
 		RotationCheckFrequency:        rotationCheckFrequency,
 		LookaheadInterval:             4 * rotationCheckFrequency, // we do 4 rotation checks ahead

cmd/tfctl/logs.go

@@ -190,7 +190,7 @@ func getPods(ctx context.Context, c *kubernetes.Clientset, ns string) ([]corev1.
 	var ret []corev1.Pod
 
 	opts := metav1.ListOptions{
-		LabelSelector: fmt.Sprintf("%s=%s", "app.kubernetes.io/name", "tf-controller"),
+		LabelSelector: fmt.Sprintf("%s=%s", "app.kubernetes.io/name", "tofu-controller"),
 	}
 	deployList, err := c.AppsV1().Deployments(ns).List(ctx, opts)
 	if err != nil {

cmd/tfctl/main.go

@@ -5,10 +5,11 @@ import (
 	"os"
 	"strings"
 
-	"github.com/flux-iac/tofu-controller/tfctl"
 	"github.com/spf13/cobra"
 	"github.com/spf13/viper"
 	"k8s.io/cli-runtime/pkg/genericclioptions"
+
+	"github.com/flux-iac/tofu-controller/tfctl"
 )
 
 var (
@@ -75,13 +76,13 @@ func newRootCommand() *cobra.Command {
 func buildVersionCmd(app *tfctl.CLI) *cobra.Command {
 	install := &cobra.Command{
 		Use:   "version",
-		Short: "Prints tf-controller and tfctl version information",
+		Short: "Prints tofu-controller and tfctl version information",
 		Args:  cobra.ExactArgs(0),
 		RunE: func(cmd *cobra.Command, args []string) error {
 			return app.Version(os.Stdout)
 		},
 	}
-	install.Flags().String("version", "", "The version of tf-controller to install.")
+	install.Flags().String("version", "", "The version of tofu-controller to install.")
 	viper.BindPFlag("version", install.Flags().Lookup("version"))
 	return install
 }
@@ -100,15 +101,15 @@ var installExamples = `
 func buildInstallCmd(app *tfctl.CLI) *cobra.Command {
 	install := &cobra.Command{
 		Use:     "install",
-		Short:   "Install the tf-controller",
-		Long:    "Install the tf-controller resources in the specified namespace",
+		Short:   "Install the tofu-controller",
+		Long:    "Install the tofu-controller resources in the specified namespace",
 		Example: strings.Trim(installExamples, "\n"),
 		Args:    cobra.ExactArgs(0),
 		RunE: func(cmd *cobra.Command, args []string) error {
 			return app.Install(os.Stdout, viper.GetString("version"), viper.GetBool("export"))
 		},
 	}
-	install.Flags().String("version", "", "The version of tf-controller to install.")
+	install.Flags().String("version", "", "The version of tofu-controller to install.")
 	install.Flags().Bool("export", false, "Print installation manifests to stdout")
 	viper.BindPFlags(install.Flags())
 	return install
@@ -117,7 +118,7 @@ func buildInstallCmd(app *tfctl.CLI) *cobra.Command {
 func buildUninstallCmd(app *tfctl.CLI) *cobra.Command {
 	return &cobra.Command{
 		Use:   "uninstall",
-		Short: "Uninstall the tf-controller",
+		Short: "Uninstall the tofu-controller",
 		Args:  cobra.ExactArgs(0),
 		RunE: func(cmd *cobra.Command, args []string) error {
 			return app.Uninstall(os.Stdout)

docs/adr/0002-deny-cross-ns-by-default.md

@@ -7,7 +7,7 @@
 
 ## Context
 
-Like [Flux](https://fluxcd.io/), the tf-controller API has a handful
+Like [Flux](https://fluxcd.io/), the tofu-controller API has a handful
 of places where it accepts cross-namespace references.
 
  - `Terraform.spec.sourceRef` -- refers to the Flux source object with

docs/adr/0003-workspace-blob-caching.md

@@ -7,7 +7,7 @@
 
 ## Context
 
-The TF-Controller currently faces challenges related to the deletion of Terraform resources.
+The Tofu-Controller currently faces challenges related to the deletion of Terraform resources.
 These problems span across three categories:
 
 1. Single object deletion,
@@ -17,21 +17,21 @@ These problems span across three categories:
 These problems must be fixed in the above order as (2) and (3) require single object deletion to be resolved first.
 
 Deleting a single TF object can sometimes be obstructed because it's tied to other resources like Source objects, Secrets, and ConfigMaps. If we try to remove it without deleting these resources, the TF object gets stuck in an inconsistent state, making it harder for users to manage their infrastructure smoothly.
-Therefore, the TF-Controller is being enhanced to address this problem more efficiently, using the contents of generated Workspace BLOBs. Each BLOB contains all necessary information from the associated Source, Secrets, and ConfigMaps to ensure that TF-Controller finalization procedures can delete objects correctly.
+Therefore, the Tofu-Controller is being enhanced to address this problem more efficiently, using the contents of generated Workspace BLOBs. Each BLOB contains all necessary information from the associated Source, Secrets, and ConfigMaps to ensure that Tofu-Controller finalization procedures can delete objects correctly.
 
-Currently, the TF-Controller downloads a Source BLOB and pushes it to a tf-runner. The tf-runner processes this BLOB to create a Workspace file system. It generates a backend configuration file, variable files, and other necessary files for the Workspace file system, using data from associated Secrets and ConfigMaps. This newly created Workspace file system is then compressed, sent back to the TF-Controller, and stored as a Workspace BLOB in the controller's storage.
+Currently, the Tofu-Controller downloads a Source BLOB and pushes it to a tf-runner. The tf-runner processes this BLOB to create a Workspace file system. It generates a backend configuration file, variable files, and other necessary files for the Workspace file system, using data from associated Secrets and ConfigMaps. This newly created Workspace file system is then compressed, sent back to the Tofu-Controller, and stored as a Workspace BLOB in the controller's storage.
 A caching mechanism for these BLOBs is essential to fixing the single TF object deletion process.
 
 ## Decision
 
 1. **BLOB Creation and Storage**
-   * A gRPC function named `CreateWorkspaceBlob` will be invoked by the TF-Controller 
+   * A gRPC function named `CreateWorkspaceBlob` will be invoked by the Tofu-Controller 
      to tell tf-runner to compress the Workspace file system into a tar.gz BLOB, which is then retrieved back to the controller.
    * The caching mechanism will be executed right before the Terraform Initialization step, ensuring that the latest and most relevant data is used.
-   * Each Workspace Blob will be cached on the TF-Controller's local disk, using the UUID of the Terraform object as the filename,`${uuid}.tar.gz`.
+   * Each Workspace Blob will be cached on the Tofu-Controller's local disk, using the UUID of the Terraform object as the filename,`${uuid}.tar.gz`.
    * To reduce the risk of unauthorized access to the cache entries, and cache collisions, the cache file will be deleted after the finalization process is complete.
 2. **Persistence** 
-   * [The persistence mechanism used by the Source Controller](https://fluxcd.io/flux/installation/configuration/vertical-scaling/#persistent-storage-for-flux-internal-artifacts) will be adopted for the TF-Controller's persistence volume.
+   * [The persistence mechanism used by the Source Controller](https://fluxcd.io/flux/installation/configuration/vertical-scaling/#persistent-storage-for-flux-internal-artifacts) will be adopted for the Tofu-Controller's persistence volume.
 3. **BLOB Encryption**
    * The encryption and decryption of the BLOBs will be tasked to the runner, with the controller solely responsible for storing encrypted BLOBs.
    * Each namespace will require a service account, preferably named "tf-runner".

docs/branch-planner/branch-planner-getting-started.md

@@ -36,13 +36,13 @@ kubectl create secret generic branch-planner-token \
     --from-literal="token=${GITHUB_TOKEN}"
 ```
 
-4. Install Branch Planner from a HelmRelease provided by the TF-Controller repository. Use TF-Controller v0.16.0-rc.2 or later.
+4. Install Branch Planner from a HelmRelease provided by the Tofu-Controller repository. Use Tofu-Controller v0.16.0-rc.2 or later.
 
 ```
 kubectl apply -f https://raw.githubusercontent.com/weaveworks/tf-controller/fa4b3b85d316340d897fda4fed757265ba2cd30e/docs/branch_planner/release.yaml
 ```
 
-5. Create a Terraform object with a Source pointing to a repository. Your repository must contain a Terraform file—for example, `main.tf`. Check out [this demo](https://github.com/tf-controller/branch-planner-demo) for an example.
+5. Create a Terraform object with a Source pointing to a repository. Your repository must contain a Terraform file—for example, `main.tf`. Check out [this demo](https://github.com/flux-iac/branch-planner-demo) for an example.
 
 ```bash
 export GITHUB_USER=<your user>
@@ -85,7 +85,7 @@ Branch Planner uses a ConfigMap as configuration. The ConfigMap is optional but
 
 ### Configuration
 
-By default, Branch Planner will look for the `branch-planner` ConfigMap in the same namespace as where the TF-Controller is installed.
+By default, Branch Planner will look for the `branch-planner` ConfigMap in the same namespace as where the Tofu-Controller is installed.
 That ConfigMap allows users to specify which Terraform resources in a cluster the Brach Planner should monitor.
 
 The ConfigMap has two fields:

docs/branch-planner/branch-planner-tfc-integration-getting-started.md

@@ -1,6 +1,6 @@
 ## Branch Planner and Terraform Cloud Integration: Getting Started
 
-With Branch Planner, you can provision the `main` branch directly on Terraform Cloud. TF-Controller communicates with Terraform Cloud to run the necessary plans and apply your approved code. The state is securely stored on Terraform Cloud.
+With Branch Planner, you can provision the `main` branch directly on Terraform Cloud. Tofu-Controller communicates with Terraform Cloud to run the necessary plans and apply your approved code. The state is securely stored on Terraform Cloud.
 
 **Note:** For now, Branch Planner only supports GitHub as the Git provider. We plan to add other Git providers in time.
 
@@ -36,7 +36,7 @@ metadata:
   namespace: flux-system
 spec:
   interval: 30s
-  url: https://github.com/tf-controller/branch-planner-demo
+  url: https://github.com/flux-iac/branch-planner-demo
   ref:
     branch: main
 ---
@@ -49,7 +49,7 @@ spec:
   interval: 2m
   approvePlan: auto
   cloud:
-    organization: weaveworks
+    organization: flux-iac
     workspaces:
       name: branch-planner-tfc
   cliConfigSecretRef:
@@ -68,7 +68,7 @@ spec:
 ### Step 3: Edit File, Create a Branch, and Open a Pull Request
 
 1. **Navigate to Your Repository:** Open a web browser and visit your GitHub repository. 
-For our example, navigate [here](https://github.com/tf-controller/branch-planner-demo).
+For our example, navigate [here](https://github.com/flux-iac/branch-planner-demo).
 
 2. **Locate the File to Edit:** Browse through the repository's file structure and 
 click on the Terraform configuration file you wish to edit.
@@ -104,7 +104,7 @@ This enables you and your team to review the expected changes before they're app
 
 2. **Iterate on Changes if Necessary**:
     - If you spot any discrepancies or wish to make further adjustments, click on the file in the `Files changed` section.
-    - After making the desired edits, commit the changes to the same branch. This will automatically prompt TF-Controller and Branch Planner to generate a new plan.
+    - After making the desired edits, commit the changes to the same branch. This will automatically prompt Tofu-Controller and Branch Planner to generate a new plan.
     - If, for any reason, the automatic replan doesn't occur or you believe there might be an inconsistency, you can manually trigger a new plan by commenting `!replan` on the PR. Branch Planner will then process the request and display the new plan results.
 
 3. **Approve the Changes**:
@@ -116,4 +116,4 @@ This enables you and your team to review the expected changes before they're app
     - With the changes approved, click on the `Merge pull request` button.
     - Choose your desired merge strategy from the options provided, such as "Squash and merge" or "Rebase and merge".
     - Click `Confirm merge`.
-    - Following the merge, TF-Controller will take over. It will send the updated Terraform configuration to Terraform Cloud, where the changes will be planned and then applied. The resulting infrastructure state will be securely stored within your Terraform Cloud workspace.
+    - Following the merge, Tofu-Controller will take over. It will send the updated Terraform configuration to Terraform Cloud, where the changes will be planned and then applied. The resulting infrastructure state will be securely stored within your Terraform Cloud workspace.

docs/branch-planner/index.md

@@ -1,8 +1,8 @@
 # Branch Planner Overview
 
-The GitOps methodology streamlines infrastructure provisioning and management, using Git as the source of truth. The Branch Planner, a component of TF-Controller, aims to take this a step further by allowing developers and operations teams to plan Terraform configurations on a branch that's separate from the `main` branch. This makes it easier to review and understand the potential impact of your changes before you run `terraform apply`.
+The GitOps methodology streamlines infrastructure provisioning and management, using Git as the source of truth. The Branch Planner, a component of Tofu-Controller, aims to take this a step further by allowing developers and operations teams to plan Terraform configurations on a branch that's separate from the `main` branch. This makes it easier to review and understand the potential impact of your changes before you run `terraform apply`.
 
-The Branch Planner's most important feature is its seamless integration with the PR (Pull Request) user interface. When enabled through Helm values, it watches repositories that contain Terraform resources at regular intervals—checking their referenced Source, and polling for Pull Requests using GitHub's API and the provided token. When changes are proposed on a new branch, Branch Planner runs a plan in the cluster and displays the results directly as comments on your PR. Once you're satisfied with the results, you can merge your branch into the `main` branch to trigger the TF-Controller to reconcile the updated code.
+The Branch Planner's most important feature is its seamless integration with the PR (Pull Request) user interface. When enabled through Helm values, it watches repositories that contain Terraform resources at regular intervals—checking their referenced Source, and polling for Pull Requests using GitHub's API and the provided token. When changes are proposed on a new branch, Branch Planner runs a plan in the cluster and displays the results directly as comments on your PR. Once you're satisfied with the results, you can merge your branch into the `main` branch to trigger the Tofu-Controller to reconcile the updated code.
 
 ![branch planner](branch-planner.png)