Support inline parameter binding in manifest file

[paulcastro]

Currently, parameter binding can only be done in a deployment file. It should be possible to do in-line parameter binding in the manifest, especially for values that are set by the developer and not intended to be changed.

One possible change is to add a value to the schema "inputs" key:

actions:
   myAction:
        inputs:
             myParam:
                  type: string
                  value: "Hello World!" 
            anotherParam:
                  type: int
                  value: 1

However, we also allow simple name value pairs without types in the deployment file. We could allow the same in the manifest without using the schema keys:

actions:
   myAction:
       parameters:
            myParam: "Hello World"
            anotherParam: 1

[paulcastro]

My preference is the second option.

[mrutkows]

This could be supported in the 0.8.3 Packaging Spec. as a variant of the first "use case" for hello world: Manifest Files:

Manifest files Example 1: No parameter descriptions

  actions:
    hello:
      version: 1.0
      function: src/hello/hello.js
      inputs:
        personName: string
      outputs:
        greeting_string: string

would need to explained further where "string" or "int" could be inferred types and have a grammar such as:

 actions:
    hello:
      version: 1.0
      function: src/hello/hello.js
      inputs:
        personName: "Fred"
        age: 30

Note: the version keys are currently required (for package management/catalog purposes); could the action versions be tied to the package version (use cases may exist to the contrary)?

[paulcastro]

I'd like a simpler approach where the version of the package applies to the entities so we don't need to explicitly assign a version number to actions, triggers, rules.

[paulcastro]

Inferred types would be good. The inputs in the YAML file get converted into a JSON based request body underneath the covers before calling the OpenWhisk REST API so any inference we make explicit in the spec should follow the JSON type inference rules.

The reason for the above is we're not doing too much with the schema definition right now. There's no validation that the type specified in the schema is converted correctly when we make the request body.

The reason I think adding a parameters key to the YAML file is the right approach is to keep the schema definition as it is using inputs and outputs. I could see useful things for it in the future (like automated schema alignment).

[paulcastro]

If we overload the inputs/outputs section to include values, I see two options.

Option 1: Preserve existing keys and add a value key

actions:
    hello:
      version: 1.0
      function: src/hello/hello.js
      inputs:
             name:
                  type: string
                  value: Paul

Option 2: Allow name value pairs as inputs

    hello:
      version: 1.0
      function: src/hello/hello.js
      inputs:
             name: Paul

Would we allow mixing and matching of the two? Or are they mutually exclusive.

Option 1 is more verbose and I usually prefer to minimize the typing. Option 2 is more compact, but causes a problem since not all parameters will take values. If we also plan to use the inputs section to determine the schema then we may not be able to use the shorthand.

This is a moot point right now since we aren't doing anything with the schema today so either option will work right now.

I'm sure there are other options, this is just what I see right now.

@mrutkows Option 2 since it is cleaner? We can revisit schemas at a later date.

[paulcastro]

merged