Add Terraform outputs to status.atProvider

[bobh66]

Signed-off-by: Bob Haddleton bob.haddleton@nokia.com

Description of your changes

Add the non-sensitive Terraform module outputs to the status.atProvider.outputs section of the Workspace object

Fixes #36

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

I tested these changes locally in a kind cluster using a mock Terraform module that outputs all 5 value types:

Spec:
  Deletion Policy:  Delete
  For Provider:
    Module:  // Modules _must_ use remote state. The provider does not persist state.
terraform {
  backend "kubernetes" {
    secret_suffix     = "xp"
    namespace         = "default"
    config_path = "/home/bobh/.kube/config"
    config_context = "kind-provider-terraform-dev"
  }
}
resource "random_integer" "foo" {
        min = 1
        max = 10
}
output "string" {
  value = "bar"
  sensitive = false
}

output "number" {
  value = 1.9
  sensitive = false
}

output "object" {
  value = random_integer.foo
  sensitive = false
}

output "tuple" {
  value = ["foo", "bar"]
  sensitive = false
}

output "bool" {
  value = false
  sensitive = false
}

output "sensitive" {
  value = "SENSITIVE"
  sensitive = true
}
    Source:  Inline
  Provider Config Ref:
    Name:  default
Status:
  At Provider:
    Outputs:
      Bool:    false
      Number:  1.9
      Object:  {"id":"9","keepers":null,"max":10,"min":1,"result":9,"seed":null}
      String:  bar
      Tuple:   ["foo","bar"]

[ytsarev]

@bobh66 thanks a lot for your contribution! Can you please investigate make check-diff locally?

[bobh66]

Hi @ytsarev - should be fixed now. Thanks!

[ytsarev]

Overall looks great, couple of suggestions

[ytsarev]

Please make check-diff again and commit :)

[bobh66]

Hi @ytsarev - it appears that exposing a "generic" output object which can contain any type to the API is either impossible or beyond my limited understanding of go. I can get it to work functionally but the tools complain about exposing an interface{} to the API schema. I thought about reusing the ConnectionDetails format but that converts everything to bytes which end up base64 encoded. Unless you have suggestions for exposing a generic object as status output, I think I need to go back to the string format for everything. The Crossplane transform "convert" option can convert strings to int/bool/etc. That leaves tuples and maps in their stringified format, so anyone using Terraform will need to expose the specific output values that they want individually, instead of exposing an entire tuple or map. Any ideas how to make the output more generic while keeping the tools happy would be greatly appreciated. Thanks!

[bobh66]

@ytsarev lint works locally, does this need a retry? Thanks

[ytsarev]

@bobh66 lint job also fails for me in another PR and also works locally - will investigate.

Regarding 'generic' status, I recall you were initially using x-kubernetes-preserve-unknown-fields which conceptually should allow arbitrary JSON. Why it didn't work?

[bobh66]

@ytsarev When I used preserve-unknown-fields I get this error from check-diff:

github.com/crossplane-contrib/provider-terraform/apis/v1alpha1:-: name requested for invalid type interface{}
github.com/crossplane-contrib/provider-terraform/apis/v1alpha1:-: invalid map value type interface{}
Error: /home/runner/work/provider-terraform/provider-terraform/apis/v1alpha1/workspace_types.go:116:21: map values must be a named type, not *ast.InterfaceType

https://github.com/crossplane-contrib/provider-terraform/runs/5767133263?check_suite_focus=true#step:8:16

which I interpreted as saying that it is not allowed to have an object defined in the API without a specified schema.

If there is a different/better way to do this I'd be happy to go back to that implementation, but I could not see a way forward from these errors.

Thanks

[ytsarev]

@bobh66 you indeed can't return interface but you should be able to return JSON and/or use https://pkg.go.dev/reflect to dynamically control the type... I will try to play with it soon

[ytsarev]

@bobh66 re lint job, it is fixed in 5f0be75 , please rebase with master. Thanks!

[bobh66]

@ytsarev What would you think about merging this as a first step, after any needed rework, and then in a separate PR we can refactor as needed to support tuples and objects? This change provides access to strings and numbers, which will be the majority of use cases.

[ytsarev]

@bobh66 agreed! Can you please rebase with master again and we are good to merge

[bobh66]

@ytsarev - done. Thanks!

[ytsarev]

@bobh66 incredibly useful contribution, thanks a lot!