Support getting the scope from the attributes of the matched resources

[dylanratcliffe]

Currently the scope for a query is taken literally. However we've known for a while this wasn't going to fly. We will need to be able to pull the scope at least from the attributes of the matched resources, and maybe from other places too (like provider config).

We need to remember that we will always need to support the following static scopes:

• global
• *

I'm thinking of maybe creating a special namespace like values (this matches what is in the plan). So if we wanted the scope to be the metadata.namespace attribute we'd use values.metadata.namespace

For kubernetes though, the scope of the resources includes the "name" of the cluster, which if course doesn't really exist. I think the solution here is to also allow the cli to map from the outputs of the plan to the scopes too. In this case we would have a well-known output such as overmind_kubernetes_cluster_name, which would be interpolated in the scope, along with the namespace. We would also need to allow the user to name the cluster arbitrarily, which would be achieved through a parameter in helm and therefore used by the source.

Then when evaluating the plan, if all of the required variables for the scope are present, then we set it, and if not then we just fall back to *. This means that people can get value immediately, but also improve their results with a little work

Interpolation format

I'm thinking we should just use the same as terraform here. e.g.

${outputs.overmind_kubernetes_cluster_name}.${values.metadata.namespace}

[dylanratcliffe]

The problem with this is the fact that you can have many of the same provider and just alias them. This means that a single outputs.overmind_kubernetes_cluster_name won't work if you are doing this. It will need to be per-resource instead. I'm thinking maybe the way to do this is to tie it to the provider. So you could output some structured data like:

---
overmind_mapping:
  # This would be the name of the provider as used in terraform.
  # So the default aws provider would be "aws", then one with
  # an alias would be aws.alias
  kubernetes:
    cluster_name: prod
  kubernetes.dev:
    cluster_name: dev

Then for each resource that is changing, we would map that resource to its provider, then use that to look up the mapping. This means that it only needs to be set once and will affect all resources which use that provider