validate ServiceInstance/Binding parameters before creating the object

[wryun]

At the moment we don't discover parameter errors until we create ServiceInstance/Binding objects.

OSB providers can/should have json schemas for their parameters. However, we can't trivially validate against these if we have any Smith references.

Unclear how to solve this. One possible solution is to make smith references include type information sufficient to generate something to pass the json schema validation (or alternatively remove or simplify the json schema in some way - e.g. strip all non-type information, or delete those fields, etc.).

Related problem: validating the type of outputs. But that's not in the OSB spec yet...

[wryun]

We discussed letting service catalog do this, but this is only reasonable if we give up on 'early' validation (i.e. before we've evaluated dependencies).

[wryun]

On further thought, I believe early validation is close to impossible due to the influence of plugins and secrets (used via parametersFrom), both of which are opaque sources of information.

Rough thoughts

Service instances/bindings

If we gave every reference an example/default value, then we could use these values to validate against the schema before evaluating dependencies.

However, we would also need to do this for secret usage in parametersFrom (e.g. make Smith understand an extended version of parametersFrom with 'example' as well as key/value, and strip before passing to service catalog). If we were going to go this far, it might make more sense to have automated secret processing in the parameters block of service instances (i.e. magically create parametersFrom based on Smith references when possible...).

Plugins

We need to be able to get to the output object before we have the dependencies - i.e. run the plugin early. The easiest way to achieve this is to remove dependencies from the plugin evaluation and rely purely on references, and then we can use the same strategy as above. I believe our current plugins can be rewritten to not rely on dependencies (and indeed should be!).

Conclusions

All of this is probably not worth it, at least in the near term. But it does seem like it would be a win to remove 'dependencies' from the plugin evaluation, and instead provide any necessary information via the spec/references. This is currently blocked by #194 and #195.