*: Updates all Reporting CRDs to v1

Updates Reports, ReportQueries, ReportDataSources, StorageLocations,
PrestoTables, and HiveTables from v1alpha1 to v1.

.gitattributes

@@ -1,4 +1,4 @@
-pkg/apis/metering/v1alpha1/zz_generated.deepcopy.go linguist-generated=true
-pkg/apis/metering/v1alpha1/zz_generated.defaults.go linguist-generated=true
+pkg/apis/metering/v1/zz_generated.deepcopy.go linguist-generated=true
+pkg/apis/metering/v1/zz_generated.defaults.go linguist-generated=true
 pkg/generated/** linguist-generated=true
 pkg/hive/hive_thrift/** linguist-generated=true

Documentation/configuring-reporting-operator.md

@@ -116,7 +116,7 @@ If your NodePorts and/or LoadBalancers are not accessible to others, then you ca
 Exposing the reporting API is as simple as changing the type of `Service` used for the reporting-operator:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: MeteringConfig
 metadata:
   name: "operator-metering"

Documentation/configuring-telemeter.md

@@ -26,7 +26,7 @@ A complete Metering configuration resource with options set for connecting to a
 
 ```yaml
 # metering-telemeter.yaml
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: MeteringConfig
 metadata:
   name: operator-metering

Documentation/hivetables.md

@@ -32,7 +32,7 @@ When created, a HiveTable resource causes the reporting-operator to create a tab
 ## Example HiveTables
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: HiveTable
 metadata:
   name: apache-log

Documentation/prestotables.md

@@ -22,7 +22,7 @@ Please read the [Presto concepts][presto-concepts] documentation to gain an unde
 ## Example PrestoTables
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: PrestoTable
 metadata:
   name: example-baremetal-cost

Documentation/reportdatasources.md

@@ -46,7 +46,7 @@ For ReportDataSources with a `spec.prometheusMetricsImporter` present, their tab
 Below is an example of one of the built-in `ReportDataSource` resources that is installed with Operator Metering by default.
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: "pod-request-memory-bytes"
@@ -61,7 +61,7 @@ spec:
 If the data to be scraped is on a non-default Prometheus instance:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: "pod-request-memory-bytes"
@@ -87,7 +87,7 @@ This example exposes the `pod-memory-request-raw` ReportQuery as a view.
 The schema is based on the `spec.columns` of the ReportQuery.
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: "pod-memory-request-raw"
@@ -106,7 +106,7 @@ For ReportDataSources with a `spec.awsBilling` present, see [here](aws-billing-d
 ### Example AWS Billing Datasource
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: "aws-billing"
@@ -129,7 +129,7 @@ A PrestoTable ReportDataSource is merely a way to expose an arbitrary table to t
 ### Example PrestoTable Datasource
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: example-baremetal-cost

Documentation/reportqueries.md

@@ -85,7 +85,7 @@ The query is not intended to be used by Reports, but instead is intended to be r
 The important things to note with this query is that it's querying a database table containing Prometheus metric data for the `pod-request-memory-bytes` `ReportDataSource`, and it's getting the table name using the `dataSourceTableName` template function.
 
 ```yaml
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportQuery
 metadata:
   name: pod-memory-request-raw

Documentation/reports.md

@@ -16,7 +16,7 @@ If the report has a schedule, it will wait until the period currently being proc
 The following example Report will contain information on every Pod's CPU requests, and will run every hour, adding the last hours worth of data each time it runs.
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: pod-cpu-request-hourly
@@ -36,7 +36,7 @@ The following example report will contain information on every Pod's CPU request
 After completion it does not run again.
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: pod-cpu-request-hourly
@@ -122,7 +122,7 @@ For a complete list of fields each report query produces, use `kubectl` to get t
 ```
 kubectl -n $METERING_NAMESPACE get reportqueries namespace-memory-request -o yaml
 
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportQuery
 metadata:
   name: namespace-memory-request
@@ -207,7 +207,7 @@ If `reportingStart` is left unset, the Report will run at the next full reportin
 As an example of how to use this field, if you had data already collected dating back to January 1st, 2019 which you wanted to be included in your Report, you could create a report with the following values:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: pod-cpu-request-hourly
@@ -229,7 +229,7 @@ If left unset, then the Report will run forever, or until a `reportingEnd` is se
 For example, if you wanted to create a report that runs once a week for the month of July:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: pod-cpu-request-hourly
@@ -312,7 +312,7 @@ The execution of a scheduled report can be tracked using its status field. Any e
 
 The `status` field of a `Report` currently has two fields:
 
-- `conditions`: Conditions is a list of conditions, each of which have a `type`, `status`, `reason`, and `message` field. Possible values of a condition's `type` field are `Running` and `Failure`, indicating the current state of the scheduled report. The `reason` indicates why its `condition` is in its current state with the `status` being either `true`, `false` or `unknown`. The `message` provides a human readable indicating why the condition is in the current state. For detailed information on the `reason` values see [`pkg/apis/metering/v1alpha1/util/report_util.go`](https://github.com/operator-framework/operator-metering/blob/master/pkg/apis/metering/v1alpha1/util/report_util.go#L10).
+- `conditions`: Conditions is a list of conditions, each of which have a `type`, `status`, `reason`, and `message` field. Possible values of a condition's `type` field are `Running` and `Failure`, indicating the current state of the scheduled report. The `reason` indicates why its `condition` is in its current state with the `status` being either `true`, `false` or `unknown`. The `message` provides a human readable indicating why the condition is in the current state. For detailed information on the `reason` values see [`pkg/apis/metering/v1/util/report_util.go`](https://github.com/operator-framework/operator-metering/blob/master/pkg/apis/metering/v1/util/report_util.go#L10).
 - `lastReportTime`: Indicates the time Metering has collected data up to.
 
 [rfc3339]: https://tools.ietf.org/html/rfc3339#section-5.8

Documentation/rollup-reports.md

@@ -10,7 +10,7 @@ In the following guide, we will create a daily report that aggregates hourly rep
 First, create the hourly report that will be aggregated:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: namespace-cpu-usage-hourly
@@ -28,7 +28,7 @@ The query below is a copy of the built-in `namespace-cpu-usage` query provided t
 It contains a few a custom inputs: most importantly, `NamespaceCPUUsageReportName` is the input we can use to pass name of our sub-report in:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportQuery
 metadata:
   name: namespace-cpu-usage
@@ -89,7 +89,7 @@ We now have a sub-report and a query that can read data from other reports.
 We can create a `Report` that uses that custom report query with the sub-report:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: namespace-cpu-usage-daily

Documentation/storagelocations.md

@@ -25,7 +25,7 @@ This first example is what the built-in local storage option looks like.
 As you can see, it's configured to use Hive, and by default data is stored wherever Hive is configured to use storage by default (HDFS, S3, or a ReadWriteMany PVC) since the location isn't set.
 
 ```yaml
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: StorageLocation
 metadata:
   name: hive
@@ -42,7 +42,7 @@ The example below uses an AWS S3 bucket for storage.
 The prefix is appended to the bucket name when constructing the path to use.
 
 ```yaml
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: StorageLocation
 metadata:
   name: example-s3-storage
@@ -61,7 +61,7 @@ If an annotation `storagelocation.metering.openshift.io/is-default` exists and i
 If more than one resource with the annotation exists, an error will be logged and the operator will consider there to be no default.
 
 ```yaml
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: StorageLocation
 metadata:
   name: example-s3-storage

Documentation/using-metering.md

@@ -26,7 +26,7 @@ The report should be created in the same namespace as Metering is installed.
 First, create an example report. Save the following into a file called `report.yaml` (times are UTC):
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: namespace-cpu-request

Documentation/writing-custom-queries.md

@@ -63,7 +63,7 @@ To configure a Metric to be collected, you need to create a [ReportDataSource][r
 Save the snippet below into a file named `unready-deployment-replicas-reportdatasource.yaml`:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportDataSource
 metadata:
   name: unready-deployment-replicas
@@ -204,7 +204,7 @@ By using inputs, we can override the default ReportDataSource used and by markin
 The format of the table names could change in the future, so always use the `dataSourceTableName` template function to ensure it's always using the correct table name.
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportQuery
 metadata:
   name: "unready-deployment-replicas"
@@ -265,7 +265,7 @@ Once we add these columns filters to our query we get the final version of our R
 Save the snippet below into a file named `unready-deployment-replicas-reportquery.yaml`:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: ReportQuery
 metadata:
   name: "unready-deployment-replicas"
@@ -317,7 +317,7 @@ kubectl create -n "$METERING_NAMESPACE" -f unready-deployment-replicas-reportque
 Save the snippet below into a file named `unready-deployment-replicas-report.yaml`:
 
 ```
-apiVersion: metering.openshift.io/v1alpha1
+apiVersion: metering.openshift.io/v1
 kind: Report
 metadata:
   name: unready-deployment-replicas

charts/metering-ansible-operator/templates/crds/hive.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: hivetables.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: hivetables

charts/metering-ansible-operator/templates/crds/prestotable.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: prestotables.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: prestotables

charts/metering-ansible-operator/templates/crds/report.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: reports.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: reports

charts/metering-ansible-operator/templates/crds/reportdatasource.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: reportdatasources.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: reportdatasources

charts/metering-ansible-operator/templates/crds/reportquery.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: reportqueries.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: reportqueries

charts/metering-ansible-operator/templates/crds/storagelocation.crd.yaml

@@ -4,7 +4,14 @@ metadata:
   name: storagelocations.metering.openshift.io
 spec:
   group: metering.openshift.io
-  version: v1alpha1
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+  - name: v1alpha1
+    served: true
+    storage: false
   scope: Namespaced
   names:
     plural: storagelocations