Insights operator API

[tremes]

This is the first part (with operator status API) and follow-up of #1193 and the original enhancement openshift/enhancements#1037

[openshift-ci]

Hello @tremes! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

For merging purposes, this repository follows the no-Feature-Freeze process which means that in addition to the standard lgtm and approved labels this repository requires either:

bugzilla/valid-bug - applied if your PR references a valid bugzilla bug

OR

qe-approved, docs-approved, and px-approved - these labels can be applied by anyone in the openshift org via the /label command.

Who should apply these qe/docs/px labels?

• For a no-Feature-Freeze team who is merging a feature before code freeze, they need to get those labels applied to their api repo PR by the appropriate teams (i.e. qe, docs, px)
• For a Feature Freeze (traditional) team who is merging a feature before FF, they can self-apply the labels (via /label commands), they are basically irrelevant for those teams
• For a Feature Freeze team who is merging a feature after FF, the PR should be rejected barring an exception

[xJustin]

/label docs-approved

[JoelSpeed]

Please make the adjustments, generate the CRD schema and then test this new API. I'd like to make sure that there's some manual testing to ensure you can set the fields to the appropriate values, eg the expected fields can be omitted, the validations work as expected

[JoelSpeed]

Do we clear this or change it at all when one is in progress? Did we work out how a user would work out that a gather is in progress? Or are we deferring that til we introduce the job style API later?

We should note what this means when it's empty or zero

[tremes]

No we don't (it can happen that a gathering is interrupted - i.e will not finish [e.g pod restart] and the time will not be set). We didn't (the information is not available now anyway) and yes I would defer this problem to force gather/job design.

So empty or zero means that there hasn't been any data gathering yet and yes let's document it here.

[JoelSpeed]

Couple of small bits but otherwise LGTM. Please test the duration validations work as expected in this case

[JoelSpeed]

Validation here too, note no zero this time as its required

Suggested change

	LastGatherDuration metav1.Duration `json:"lastGatherDuration"`
	// +kubebuilder:validation:Pattern="^([0-9]+(\\.[0-9]+)?(ns|us|µs|ms|s|m|h))+$"
	LastGatherDuration metav1.Duration `json:"lastGatherDuration"`

[JoelSpeed]

/test verify

I think that's a flake

Otherwise LGTM
/lgtm

[JoelSpeed]

/test verify

[JoaoFula]

/label qe-approved

[sferich888]

/label px-approved

[deads2k]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, JoelSpeed, tremes

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [deads2k]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@tremes: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.