Skip to content
This repository has been archived by the owner on Jan 13, 2021. It is now read-only.

Consider making plugins even purer functions #205

Open
wryun opened this issue Jan 10, 2018 · 0 comments
Open

Consider making plugins even purer functions #205

wryun opened this issue Jan 10, 2018 · 0 comments
Labels

Comments

@wryun
Copy link
Contributor

wryun commented Jan 10, 2018

If we support #194 and #195, and we want to do #186 and #187, then one option would be to stop supporting plugins as a separate top-level 'thing' and instead allow references to call user provided functions.

e.g. rather than doing:

  - name: compute--secretenvvar
    dependsOn:
    - compute--basic--binding
    - compute--mykinesis--binding

    spec:
      plugin:
        name: secretenvvar
        objectName: compute--secretenvvar
        spec:
          outputJsonKey: secretEnvVars
          outputSecretKey: ec2ComputeEnvVars

One would instead do:

  - name: compute--secretenvvar
    dependsOn:
    - compute--basic--binding
    - compute--mykinesis--binding
    spec:
      metadata:
        name: b
      apiVersion: v1
      kind: Secret
      stringData:
        ec2ComputeEnvVars: {{buildSecretObject(*#*)}}

i.e. plugins simply provide some set of simple functions which you can pass parameters to. Here # is shorthand for all outputs of all dependencies, but for most plugins you're likely to want more specific values (for either deps or outputs).

Why is this useful?

  • it's considerably clearer what's going on in terms of kubernetes objects than using plugins as they stand
  • we go back to the state of Smith only supporting 'objects' in the spec (no additional nesting/confusion)
  • we're closer to supporting schema based validation (if using functions in ServiceInstance objects)

Yes, we do make the references more complex, and yes, this is looking more like what RPS does (in terms of jmespath functions and more complex references)... we could just use jmespath here ;) Just saying.

@ash2k ash2k added the design label Jan 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants