Conversation
| conditions.MarkFalse(hm, infrav1.ServerCreateSucceededCondition, | ||
| "ServerCreateNotPossible", clusterv1.ConditionSeverityWarning, | ||
| "%s", err.Error()) | ||
| if !conditions.IsFalse(hm, infrav1.ServerCreateSucceededCondition) { |
There was a problem hiding this comment.
is this relevant? To me it sounds like we should stick to one version (in the utility function) or here, but not both
There was a problem hiding this comment.
@janiskemper what is the desired result?
Currently (pre PR):
reason="ServerCreateNotPossible" message="createServerFromImageNameOrURL failed: create server from imageName ("my-control-plane-2"): no image found with name my-control-plane-2: server create not possible - need action"
But test expected reason="ImageNotFound".
I slightly prefer ImageNotFound, but the more general reason is fine, too.
There was a problem hiding this comment.
I also do that. So we should not overwrite it. But my point is that we should find a better solution ideally, not this if statement. @Dhairya-Arora01 can also look into this if you want.
There was a problem hiding this comment.
@janiskemper what about merging it like it is now, and make it nice in a second PR. The CI fails for other PRs now, and I would like to fix v1.1.x soon.
There was a problem hiding this comment.
@abdullah599 then plz look into that. If we have another issue, we can merge this
There was a problem hiding this comment.
I did this (i'll revert it). I did not know we fixed it here
reason:
ServerCreateSucceededCondition are already set with the specific reason by the inner function that returned errServerCreateNotPossible. imo we must not overwrite them here.
The guard isn't needed imo. Every code path that returns errServerCreateNotPossible already sets ServerCreateSucceededCondition to False with a specific reason before returning:
createServer→InstanceHasNonExistingPlacementGroupReasongetSSHKeys→SSHKeyNotFoundReasongetServerImage→ServerTypeNotFoundReasongetServerImage→ImageAmbiguousReasongetServerImage→ImageNotFoundReason
So conditions.IsFalse(hm, infrav1.ServerCreateSucceededCondition) is always true when this handler runs.
There was a problem hiding this comment.
so we can just remove this right?
There was a problem hiding this comment.
@abdullah599 yes, maybe it works for now to remove that block completely. But who know if the future paths all set a condition. I recommend to leave it like this.
There was a problem hiding this comment.
@guettli I wouldn't leave it like this, because the problem shouldn't exist in the first place, if this code part is removed.
| Eventually(func() bool { | ||
| return isPresentAndFalseWithReason(key, hcloudMachine, infrav1.ServerCreateSucceededCondition, infrav1.ImageNotFoundReason) | ||
| }, timeout, interval).Should(BeTrue()) | ||
| Eventually(func() error { |
There was a problem hiding this comment.
why do we do this? If the utility function has some issues, we oculd also solve it there probably no? I'm not able to judge on first glance what changed.
There was a problem hiding this comment.
@janiskemper before we got an meaningless "false is not true" error. We get much better error now, when the test fails:
expected ServerCreateSucceeded to be False with reason "ImageNotFound",
got status="False" reason="ServerCreateNotPossible" message="createServerFromImageNameOrURL failed: create server from imageName ("my-control-plane-2"): no image found with name my-control-plane-2: server create not possible - need action"
For new code I prefer Eventually(func() error to Eventually(func() bool
But I can revert that, too. Or we write a helper which makes getting a good error message easier.
There was a problem hiding this comment.
well this applies to all cases where we use this utility function. Do we have an idea how to improve that?
There was a problem hiding this comment.
Added a reusable helper in test/helpers/conditions.go and switched only this Eventually to use it.
I reverted the broader rollout so this PR stays scoped to the original failing case. If we want to apply the same pattern to the other isPresentAndFalseWithReason usages, I can do that in a separate follow-up PR.
There was a problem hiding this comment.
@guettli can you plz write down properly what your problem is with the isPresentAndFalseWithReason utility and then why you wanna change it and what you propose? I think that we either properly change the original utility function, we introduce a separate utility function, or we do it differently in this one case.
If no change is needed here for this PR, I would leave the topic, revert the changes, and create an issue for it.
There was a problem hiding this comment.
janiskemper
left a comment
There was a problem hiding this comment.
LGTM from my side. @abdullah599 is that what you had in mind as well?
abdullah599
left a comment
There was a problem hiding this comment.
LGTM from my side. @abdullah599 is that what you had in mind as well?
Yes :)
Fix unit-tests on v1.1.x.
Failed before:
DEBUG=1 ginkgo run --focus "without placement groups" ./controllers/... | ./hack/filter-caph-controller-manager-logs.py -