Explain where each parameter came from in porter installation show

[carolynvs]

In v1 porter installation show has a bit more information that we are going to present to the user, such as the names of the parameter sets that you used when you installed the bundle. Also we will show the parameter values too.

I was wondering if it would be helpful to see where the parameter value "came from"? The source could be a user override with --param or the name of the parameter set.

Name: mywordpress
Namespace: dev
Created: 2020-04-18
Modified: 2020-04-18

Bundle:
  Repository: getporter/wordpress
  Version: 0.1.0

Labels:
  io.cnab/app: wordpress
  io.cnab/appVersion: v1.2.3

Parameters:
----------------------------------------------
  Name      Type     Value       Source
----------------------------------------------
  logLevel  integer  3           user
  token     unknown  top-secret  parameter set
  plugins   string   shopify     wordpress-tweaks

Parameter Sets:
  - dev-env
  - wordpress-tweaks

I think it would help with debugging but it's a bit of extra work for Porter to remember the sources so it would have to be a clear win to add this to the backlog. Thoughts?

[carolynvs]

On a related note, when I switched the data structure exported in porter installation show NAME -o json|yaml, calculated fields (such as the full set of parameters used with an installation) are no longer included in the machine readable formats. Since at the moment we are only printing the installation document, and not the display installation document.

I made that change so that you could use porter show -o json > myinstall.json -> porter apply -f myinstall.json.

I want to find a safe way to export this extra information while still yielding a valid importable installation document. One thought is that we change how we define and build the DisplayInstallation structure. We could have it be composed of an installation and then have extra fields that store calculated data. The output for porter show would always be based on DisplayInstallation. Yes the json/yaml would have extra calculated fields, but they would be ignored when imported (just like we ignore status when we import). If we grouped them or named them properly then people would know to ignore them.

type DisplayInstallation struct {
  claims.Installation `mapstructure:",inline"

  Calculated DisplayInstallationMetadata `mapstructure:"_calculated"
}

type DisplayInstallationMetadata struct {
  LastRun claims.Run `mapstructure:"lastRun"
}

name: foo
namespace: dev
...

_calculated:
  lastRun:
    Id: abc123
    action: install