Epic: Operator v1.0 Tracker

[schristoff]

We have Github Boards at the org level, which is great, but it can be difficult to capture conversations in there.
Operator v1.0 is scheduled for code freeze September 27th, with a release of September 30th.

The board for tracking v1.0 is here

The items without issues should have issues made, but I just haven't gotten around to it yet

Code 👩‍💻

• Porter fails auth for installation image pull with Kubernetes driver
  
• Expose bundle outputs inside a cluster #63
• Delete temporary resources when agent completes #54
  • Add TTL for porter plugin volume if no version is configured #134 (depends on Delete temporary resources when agent completes #54)
• How to upgrade the porter operator from within K8s #32

Docs ✍️

• Create demos section - user created demos welcome! Create /demos and move operator-argo demo inside Operator #210 (We currently are seeking demos for GKE/AWS and anything else!)
• Update Documentation, especially getting started (docs): Make Quickstart More User Friendly #261
• Blog for release of v1.0
• Matrix for clouds and stuff we support (update!)

[troy0820]

For #63

I know we use the porter cli as a "agent" to surface the outputs from the output of the cli.
Questions around this issue:

1. Are we creating a GRPC service to expose this where we still have to do this (the porter cli)?
2. Are we also creating a CRD to have that be a thing?
3. Are all outputs created equal?
4. What outputs do we want? Paramsets, etc
5. A lot of things are stored in state by the mongodb database and are we running that along side of the porter operator to capture this?
6. Each job that creates the porter cli invocation has to run the mongodb driver (or whatever backend it needs) to achieve the state of updating, etc porter bundles, do we want to offload this to etcd as the source of truth?

(I may edit these questions as more things come to mind)