Home for notes/TODOs/etc. around getting downstream CI green by the end of the sprint.
To expediate the process of deploying Metering, you can create the requisite OLM custom resources locally, using the openshift client.
- 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.
- 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.
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
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.
$ make bin/deploy-metering
- Deploy package: kube-reporting/metering-operator#921
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.
(This needs to be updated to let a user have Ansible create a secret for them, and they provide the cert/key/caCert)
[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.
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.
export METERING_NAMESPACE="your namespace"