Hello,

I see there is a examples/tf-native folder with *.tf files. Is it possible to use external *.tf files instead of using spec.hcl yaml blocks?

Thanks!

Jun

Currently all jobs are run in the namespace the configuration CRD is created in, which given how the provider secret implementation works (copying the secret into the desiganated namespace) exposes central credentials. This PR adds a conntroller flag (--controller-namespace) which runs all jobs in a specific namespace and ensuring any secrets are never exposed beyond that boundary.

• Also add the ability to run the jobs under a serviceaccount, extending the Provider CRD. When run via the --job-namespace the platform administrator can provision a service account with Pod identity (EKS IRSA) and remove the need for static secrets.

This change adds support for the EC module in terraform-controller. Without this change the EC provider for Elastic Cloud cannot be used via the terraform-controller because it does not know how to find secrets.

This is a PR to Support SSH for retrieving terraform modules in private git repo for this issue: https://github.com/kubevela/terraform-controller/issues/292 There is a corresponding PR in kubevela repo: https://github.com/kubevela/kubevela/pull/5059

This change require a secret which hold the SSH private key and known hosts for the git repo: known_hosts can be generated using ssh-keyscan <git-url>

apiVersion: v1
kind: Secret
metadata:
  name: git-ssh
  namespace: vela-system
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: |
   <SSH Private Key> # the ssh private key used for authenticating git
  known_hosts: |
   <SSH known_hosts>  # use `ssh-keyscan github.com`  to generate known_hosts

This pr is supposed to implement the proposal which is the concluation of the issuse #288 .

Currently, the changes only add some fields to the spec.backend to enable the end-users to custom the Terraform backend configuration.

Signed-off-by: loheagn [email protected]

The map type object are not getting read into into terraform variable .It always complains that the variable being read into always comes empty. The file doesn't define case for handling map type object. https://github.com/oam-dev/terraform-controller/blob/master/controllers/configuration/convert.go

I use terraform-controller to deploy helm releases.

Everything goes fine in my dev env, but sometimes terraform init will stuck in fetching providers from terraform registry due to network issue

I see all volumes mounted in apply-job is emptyDir and mounted as a directory, a 'pre-init' images with all providers downloaded can not work as expected

Maybe there should be something like "-plugin-dir" from terraform init command

when the configuration is outside of the namespace of the job in this case the controllerNamespace, the owner reference causes de job to be garbage collected and continuosly be recreated

As we are using .Release.Namespace in the chart, it's not friendly for local development. @lewis-od Any suggestions?

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/oam-dev/terraform-controller/chart/templates git:(aws-example) ✗ k apply -f .
role.rbac.authorization.k8s.io/read-provider-creds created
clusterrole.rbac.authorization.k8s.io/tf-api-role configured
clusterrole.rbac.authorization.k8s.io/tf-controller-clusterrole created
role.rbac.authorization.k8s.io/tf-controller-role created
error parsing terraform_controller.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_api_role_binding.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_controller_clusterrolebinding.yml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_controller_role_binding.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_controller_service_account.yml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_executor_role.yml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_executor_rolebinding.yml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}
error parsing tf_executor_service_account.yml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Release.Namespace":interface {}(nil)}

For now if restart controller with --controller-namespace. The configuration state will become GeneratingTerraformOutputs and stuck. This is because controller can't got the legacy backend.

Fix that Configuration.Spec.Backend will be overwritten if set --controller-namespace. Instead, now controller only overwrite Configuration.Spec.Backend when no backend specified.

How is this tested

Add both unittest and e2e test

Signed-off-by: Qiaozp [email protected]

A Configuration won't get deleted when its namespace is being deleted. Please look into the details of this issue, please refer to https://cloud-native.slack.com/archives/C01BLQ3HTJA/p1656829163511879.

Here are the steps to reproduce the issue.

• Apply the Configuration

apiVersion: terraform.core.oam.dev/v1beta2
kind: Configuration
metadata:
  name: random-e2e
  namespace: n1
spec:
  hcl: |
    resource "random_id" "server" {
      byte_length = 8
    }
    
    output "random_id" {
      value = random_id.server.hex
    }

  inlineCredentials: true

  writeConnectionSecretToRef:
    name: random-conn
    namespace: default

• When the Configuration becomes ready, delete namespace n1.

The deletion of the Configuration got stuck and there are issues in the log of Terraform Controller.

apiVersion: terraform.core.oam.dev/v1beta2
kind: Configuration
metadata:
  name: random-e2e
  namespace: n1
spec:
  hcl: |
    resource "random_id" "server" {
      byte_length = 8
    }
    
    output "random_id" {
      value = random_id.server.hex
    }

  inlineCredentials: true

  writeConnectionSecretToRef:
    name: random-conn
    namespace: default

Sometimes users want to use customized .terraformrc and credentials.tfrc.json files. Here's one use case:

• Use self-hosted JFrog Artifactory to proxy and cache AWS provider resource. These two files are used to point to the self-hosted services and provide credentials.

We should support mount volumes for each file when apply jobs.

Configuration like:

apiVersion: terraform.core.oam.dev/v1beta2
kind: Configuration
metadata:
  name: custom-rc
spec:
  cliConfiguationSecretRef:
    name: cli-conf
    namespace: default
  remote: <module>
  ...

And the Secret like:

apiVersion: v1
kind: Secret
metadata:
  name: cli-conf
  namespace: default
data:
  terraformrc: |
   ...
  credentials.tfrc.json: |
   ...

Hi kubevela/terraform-controller!

This is a one-off automatically generated pull request from LGTM.com :robot:. You might have heard that we’ve integrated LGTM’s underlying CodeQL analysis engine natively into GitHub. The result is GitHub code scanning!

With LGTM fully integrated into code scanning, we are focused on improving CodeQL within the native GitHub code scanning experience. In order to take advantage of current and future improvements to our analysis capabilities, we suggest you enable code scanning on your repository. Please take a look at our blog post for more information.

This pull request enables code scanning by adding an auto-generated codeql.yml workflow file for GitHub Actions to your repository — take a look! We tested it before opening this pull request, so all should be working :heavy_check_mark:. In fact, you might already have seen some alerts appear on this pull request!

Where needed and if possible, we’ve adjusted the configuration to the needs of your particular repository. But of course, you should feel free to tweak it further! Check this page for detailed documentation.

Questions? Check out the FAQ below!

FAQ

A few users kept asking whether we can support preventing cloud resources from being deleted. We asked them to use the delete protection feature if the cloud provides the option like https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/ess_scaling_group#group_deletion_protection.

Now Terraform officially provides prevent_destroy in lifecycle with a resource since v1.3 https://developer.hashicorp.com/terraform/tutorials/state/resource-lifecycle#prevent-resource-deletion. We might also need to support it.

Feature Request

Now we will dispatch destroy job if Configuration is deleted. However, sometimes no resources is created due to the wrong Configuration. In this case, we should detect the resource creation phase and skip the destroy phase depends on the situation.

1. What https://github.com/kubevela/kubevela/pull/3929 do

In deletion part, kubevela#3929 will set configuration.spec.forceDelete to true. Anything else is dealt with terraform-controller.

Origin Post

Hey, I know this is merged, but I realized when you have something wrong the deletion don't complete. For example, Imagine you go to the Cloud provider portal and delete the resource, terraform will fail to delete saying the resource doesn't exist, like this:

Error: Error: Subnet: (Name "subnet-1" / Virtual Network Name "vnet-1" / Resource Group "example1") was not found

The same happen if I accidentally make a mistake in a HCL and apply some components in an application, but try to delete after realize I did a mistake, the delete never happen.

I just did it on my test environment and can't delete the application even using force.

I receive a:

Deleting Application "vm-1"
force deleted the resources created by application
successfully cleanup the resources created by application, but fail to delete the application
Error: timed out waiting for the condition

Originally posted by @alisson276 in https://github.com/kubevela/kubevela/issues/3929#issuecomment-1143801240

the providerConfig for crossplane's provider-terraform supports git-credentials file for authentication to pull the terraform module from private git repo. ref: https://github.com/crossplane-contrib/provider-terraform#private-git-repository-support

kubevela's terraform provider should support private git using similar mechanism since it is already doing so for cloud credentials e.g. AWS through the provider