Create secrets automatically if secrets passed in ServiceInstance/Binding parameter blocks (automated parametersFrom) about smith HOT 6 OPEN

New proposal (thanks for discussing and holding off on lunch, @ash2k !):

References are currently made up of two parts, dependsOn (essentially just to make the typing clearer and processing more trivial) and the reference itself (which contains all the information about the reference). We should instead invert this relationship, so that all the information (jsonpath, secret, example, etc.) is concentrated in the dependsOn, where there is room for structured data, and the reference itself becomes as empty as possible. This cleans up not only 'how to make things optionally secret', but also gets rid of the messy example syntax.

i.e. something like:

  - name: binding1
    dependsOn:
    - instance1
    spec:
      object:
        apiVersion: servicecatalog.k8s.io/v1beta1
        kind: ServiceBinding
        metadata:
          name: binding1
        spec:
          instanceRef:
            name: "{{instance1#metadata.name#"exampleName"}}"
          secretName: secret1  

Becomes:

  - name: binding1
    references:
      instanceRef:
        resource: instance1
        path: metadata.name
        example: instanceName
        secret: false
    spec:
      object:
        apiVersion: servicecatalog.k8s.io/v1beta1
        kind: ServiceBinding
        metadata:
          name: binding1
        spec:
          instanceRef:
            name: "!{instanceRef}"
          secretName: secret1  

Note that escaping can be done by repetition of '!' (i.e. !{x} is a reference to x, and !!{x} is the raw string !{x}, etc.). We could make this a list instead of a map to be more kube like, but it fits very well with the concept of a map... (i.e. instanceRef -> blah).

Another option here would be to remove the reference from the parameter entirely, and instead specify an 'output path' in the reference. This would mean we would never have invalid typed data (i.e. string where expecting an object), but would make the templates considerably more opaque.

from smith.

Ok, the thing I didn't properly consider was that we sometimes used dependsOn in the absence of actual references. Not sure how essential this is - we can always force it by having an 'empty' Reference (i.e. just the resource and nothing else...). Thoughts?

from smith.

Add an attribute "unused: true" and error if not set to true but not used?

from smith.

A bit messy, though. At the moment I'm not checking usages at all... not sure if I should or not. Maybe it's always an error if you specify a Path and don't use it? (not as explicit, of course...)

from smith.

I think we should check if a reference is used, otherwise it may be hurting concurrency and... it's just junk that should be cleaned up.
I like the idea with empty/optional path. 👍

from smith.

Now that we have the reference refactoring, I think this is as simple as allowing complex references into secrets so that we can 'autowire' them appropriately (and get rid of crazy secret plugins...).

See also: #263

EDIT: though this would require the autowiring functions to know about the outputs. I'm... surprisingly ok with this.

from smith.