PoC for general processing of status conditions for multiple operands

[tremes]

This is just a proposal (maybe too many unstructured and type converting) for more general processing of status conditions for multiple operands. Only one shared Condition type is assumed (see #434 (comment)).

The idea is based on the Operand type (see here), which is a wrapper for client.Object, but also introduces flags that tell what it affects in terms of status conditions.

The disadvantage is that the condition is overwritten (see here, it also means that the order of the operands matters) and we could probably think about some more sophisticated "aggregating" approach.

Question is how to calculate or aggregate the observedGeneration value when a stack has more than operand.

[tremes]

Perhaps we could avoid this function by using some interface like:

type StatusReporting interface {
	Conditions() []Condition
	Geeneration() int64
}

And require types like MonitoringStack to implement this interface.

[tremes]

@jan--f I was updating this PR this morning a bit (locally so far) and I think this ^^ can probably make few things more simple here.
What do you think about this idea? The Operand type introduced here can then use this StatusReporting type instead of client.Object (but it's just theory. I haven't tried yet)

[tremes]

Hm actually the theory was not correct :) I guess it won't help much with the conditions reading from the operands.

[jan--f]

yeah I see.
Could we perhaps use generics to implement the update* functions? The idea would be to simply provide a helper function that implements what's described in https://docs.google.com/presentation/d/1f-0UtZB8RvIlw49pBYCLfLfWeRflUYo2bJvkKpL2sRo/edit#slide=id.g28d2c6c7c1e_0_10
wdyt?

we certainly could make do without this, but maybe this is nice chance to testdrive golang generics :)

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tremes

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/OWNERS [tremes]
• test/OWNERS [tremes]

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: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/observability-operator-e2e	5680b97	link	true	/test observability-operator-e2e

Full PR test history. Your PR dashboard.

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.