Extend installation metadata and commands

[carolynvs]

As I have been working on how we can add namespaces, labels and log retention to Porter, it has become clear that we need more metadata and commands at the installation level. I just opened an issue in the spec to see if we can make this spec level, instead of custom metadata. We will want to figure that out before we design so we know where we are storing data.

Show Installation

• Display the new fields for namespace and labels
• Display the log retention policy
• Change "history" to "revisions" and include the revision number from the claim so that people can reference it.
• Show the bundle reference that will be used when the installation is run without specifying --reference. We need to start storing this value on the installation, currently it's calculated (poorly).

$ porter installation show INSTALLATION [--namespace NAMESPACE]
Name: porter-hello
Namespace: demos
BundleReference: getporter/porter-hello:v0.1.0
Created: 2021-02-11
Modified: 2021-02-26
LogRetentionPolicy:
  # RetainN
  # RetainFailed
  # RetainAll

Labels:
  app: hello
  demo: true

Revisions:
----------------------------------
  Revision Action   Timestamp   Status
----------------------------------
  abc123   install  2021-02-11  failed
  abc123   install  2021-02-18  succeeded

Modify installation values

We should add set to credentials/parameters so people can edit with their cli or editor.

Set a label

$ porter installation set INSTALLATION [--namespace NAMESPACE] --label KEY=VALUE

Set the log retention policy

The policy defaults to a value set in the configuration when the installation is first created, default-log-retention-policy or something. Make sure that we are clear that it only applies on create, afterwards we use what's set on the installation.

$ porter installation set INSTALLATION [--namespace NAMESPACE] --logRetension STRATEGY

We should plan on allowing for strategies, e.g. Keep the last N, Keep all failed, Keep all. Keep nothing is represented by Keep last 0. This part needs more design and identification of future strategies so that we don't break the schema later.

Edit the installation

Open their EDITOR (warning and ignoring changes to readonly fields)

$ porter installation edit INSTALLATION [--namespace NAMESPACE]

List revisions

• This is the same data that is displayed in porter installation show. Maybe once we have a separate command we don't need to retrieve it there if it's expensive.

$ porter installation revision list INSTALLATION [--namespace NAMESPACE]
----------------------------------
  Revision Action   Timestamp   Status
----------------------------------
  abc123   install  2021-02-11  failed
  abc123   install  2021-02-18  succeeded

Show a particular bundle execution (aka claim)

• I don't think we need namespace here, revision is unique but it may be necessary just to make data access easier
• BundleReference is the reference used for this particular run.
• Show labels applied to that run (e.g. a unique value that the porter operator applied to it). Set with porter install --label KEY=VALUE.
• Finally let people see the parameters used with a run and the outputs for that run, not just the last set of outputs.
• Can we show the name of the credential set or is that sensitive? It could be pretty helpful.

$ porter installation revision show REVISION [--namespace NAMESPACE?]
Revision: abc123
Installation: HELLO
Namespace: demos
BundleReference: getporter/porter-hello:v0.1.0
Start: TIME
Stop: TIME
Status: succeeded

Labels:
  porter-operator-revision: def456

Parameters:
List parameters used

Outputs:
----------------------------------------------------------
  Name       Type    Value
----------------------------------------------------------
  cluster    string  carolynvs
  kustomize  file    PK
                     T�AR#cnab/app/v1.2-deployment/ku...

Show logs from a run

When --installation is used instead of revision, display the logs from the last run. When logs aren't available, return a non-zero exit code and print "No logs retained from installation INSTALLATION revision REVISION". When the run isn't complete, tell them to wait because logs are collected at the end of a run. 😀

$ porter installation logs show [--revision REVSION] [--installation INSTALLATION] [--namespace NAMESPACE]
Giant dump o' logs

We can create a new item type, logs, to store logs using the existing crud interface in cnab-go.

Show outputs from a run

Add --run and require either a run (claim id) or the installation. People can get the Run ID from the installation history.

$ porter installation logs show [--revision REVISION] [--installation INSTALLATION] [--namespace NAMESPACE]