PoC for general processing of status conditions for multiple operands#447
PoC for general processing of status conditions for multiple operands#447tremes wants to merge 5 commits intorhobs:mainfrom
Conversation
tremes
requested review from
simonpasquier and
slashpai
and removed request for
a team
pkg/status/conditions.go
Outdated
| return v1alpha1.Condition{}, fmt.Errorf("ERROR: condition type %v not found", t) | ||
| } | ||
|
|
||
| func getConditionsFromObject(o client.Object) ([]v1alpha1.Condition, error) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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)
There was a problem hiding this comment.
Hm actually the theory was not correct :) I guess it won't help much with the conditions reading from the operands.
There was a problem hiding this comment.
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 :)
tremes
force-pushed
the
conditions-universal-qmark
branch
from
8f3f336 to
fa1a3e1
Compare
|
[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 DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tremes
force-pushed
the
conditions-universal-qmark
branch
from
fa1a3e1 to
5680b97
Compare
|
@tremes: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
This needs updates and it would probably be good to split into more PRs. |
3 participants
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
Conditiontype is assumed (see #434 (comment)).The idea is based on the
Operandtype (see here), which is a wrapper forclient.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
observedGenerationvalue when a stack has more than operand.