Skip to content

Instantly share code, notes, and snippets.

@timflannagan
Created May 26, 2020 19:53
Show Gist options
  • Save timflannagan/64446cbc3b4c29051419981399dfa852 to your computer and use it in GitHub Desktop.
Save timflannagan/64446cbc3b4c29051419981399dfa852 to your computer and use it in GitHub Desktop.

TODO

  • Investigate upgrading Metering when using the Manual approval strategy.
  • Investigate upgrading Metering when the newer, 4.5 channel is available and Automatic approval strategy has been configured.
  • Verify the Automatic approval strategy behavior when a 4.4 cluster is upgraded to 4.5
  • Map out any scenarios where a Metering upgrade could fail
  • What's the rollback process - what happens when the process of upgrading Metering to 4.5 fails, and we need to rollback to 4.4? -- Does OLM track the previous CSV version
  • Flesh out what are sufficient checks to ensure a Metering installation is "healthy" - this translates to post-upgrade checks as well.
  • Investigate the openshift-docs k8s custom resource syntax and conform to that standard -- Ping Kevin L. about the syntax, e.g. ReportDataSource vs. ReportDataSource vs. report data source. -- Investigate Metering vs. metering vs. Metering Operator
  • Investigate monitoring last seen (or last timestamp modified) for post-upgrade debuggability/verification checks
  • Investigate getting the MeteringConfig status field output w/o using an external tool, like jq.
  • Investigate what are good post-upgrade k get reportdatasource column verification checks to ensure post-upgrade success.
  • Investigate if there are any good, simple post-upgrade Report verification checks
@timflannagan
Copy link
Author

Since the last sync:

  • Added quick write-up for release-4.5 notes: https://gist.github.com/timflannagan1/9cd998945a2521b2bcbd1db86904322e
  • Lindsey added documentation and examples around tracking events. Dial down on the language used and whether or not it's too generalistic.
  • Investigate documenting the MeteringConfig status. This is useful for tracking down errors that may have occurred in the Ansible role while rolling out the Metering stack.
  • Another open question is what's the most consumable way to track the progress of the Metering operator stack. Traditionally, this would be via events, but we need to double-check what's the more reliable implementation under the hood.
  • Figure out a decent Report that ensures that Metering is still functioning as intended, after the upgrade process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment