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"
(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.
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 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
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
Manual approval strategy.Automatic approval strategy has been configured.Automatic approval strategy behavior when a 4.4 cluster is upgraded to 4.5ReportDataSource vs. ReportDataSource vs. report data source.
To expediate the process of deploying Metering, you can create the requisite OLM custom resources locally, using the openshift client.
CatalogSource custom resource (e.g. qe-app-registry) that contains the metering-operator's manifest bundle.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.
Home for notes/TODOs/etc. around getting downstream CI green by the end of the sprint.