timflannagan

Overview of Process:

In able to enable Presto to work with TLS and authentication, we first need to create server, client, and CA certificates and keys. Then, we need to create multiple secrets locally that store these certificates and keys. Once that is done we can move on to configuring our k8s resources and custom MeteringConfig resource.

Setup metering namespace:

export METERING_NAMESPACE="your namespace"

Creating the necessary certificates

timflannagan

(This needs to be updated to let a user have Ansible create a secret for them, and they provide the cert/key/caCert)

Overview:

[MC-545] Introduces a top-level tls key in the metering charts.

The ansible-operator is configured to automatically generate the necessary certificates and keys so that Presto components, and Presto to reporting-operator can communicate.

The key tls.enabled is currently defaulted to true, meaning if you wanted to enable TLS yourself you would need to specify tls.enabled: false in your meteringconfig CR.

MeteringConfig:

timflannagan

Overview of Changes:

This PR configures spec.reporting-operator.spec.authProxy by default. Like other PRs, we do this using the top-level spec.tls.enabled key, which is set to true by default.

When you run a minimal meteringconfig CR (still need to specify some sort of storage), the ansible-operator will set authProxy.enabled: true.

We check if a authProxy.cookie.secretName: reporting-operator-auth-proxy-cookie-seed already exists. If it does, we pull the existing data out, and let ansible re-template/re-create that secret. However, if that secret name doesn't exist, we generate a random 32-bit character string, and create the cookie seed secret using that value.

As a reminder, if you want to manually configure TLS/auth yourself, you would need to set spec.tls.enabled: false in your meteringconfig CR.

timflannagan

Overview

This would add another Go package aimed at emulating the manual install/uninstall logic that's currently done in the hack/install.sh andhack/uninstall.sh scripts. When interacting with the deploy-metering binary, you have the choice of using the command flags available, or their respective environment variable. In the case where both the flag, and the environment variable are specified, the flag value takes precedence.

Building the binary

$ make bin/deploy-metering

Link to PRs:

1. Deploy package: kube-reporting/metering-operator#921

timflannagan

Overview

During the 4.2 development cycle, support for installing metering on a vanilla kubernetes cluster was implemented. Previously, you had to manually tweak and configure pod security permissions and disable TLS/OCP-only features yourself.

In order to do this, the metering-ansible-operator was updated to work with another set of override variables that's contingent on the value of the MeteringConfig field spec.disableOCPFeatures, being set to true. Alternatively, if running metering locally (via make run-metering-operator-local), you can set the $DISABLE_OCP_FEATURES environment variable to true.

This also added another set of manifest files (manifest/deploy/upstream) which are used to install the upstream package which is available via the community-operators package in OperatorHub.io.

Before proceeding to the installation section, see the prerequisites section for instructions on setting up a kub

timflannagan

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.

timflannagan

Overview

To expediate the process of deploying Metering, you can create the requisite OLM custom resources locally, using the openshift client.

Prerequisites

• Need an existing CatalogSource custom resource (e.g. qe-app-registry) that contains the metering-operator's manifest bundle.
• Verify that there's a metering-ocp packagemanifest. Note: there's some naming collision with the qe-app-registry and redhat-operators packages, but you should be able to tell if there's no populated publisher field for the package.

Procedure

timflannagan

Overview

Home for notes/TODOs/etc. around getting downstream CI green by the end of the sprint.

Table of Contents

1. Setting up cluster test environment
2. Individual test case failures
   1. "Catalog represents a store of bundles which OLM can use to install Operators image update"
3. "Disabling copied CSVs when an operator is installed in AllNamespace mode should have Copied CSVs in all other namespaces"