e2e test occasionally fail for ResourcePool Scheduling

[Svarrogh1337]

Bug description

E2E tests are unstable due to ResourcePool Scheduling - Ordered occasionally failing.

How to reproduce

E2E test fail due to expected message not matching claim.Status.Condition.Message

What we expect:
requested: limits.cpu=2, queued: limits.cpu=4; requested: requests.cpu=2, queued: requests.cpu=4
What occasionally claim.Status.Condition.Message contains:
requested: requests.cpu=2, queued: requests.cpu=4; requested: limits.cpu=2, queued: limits.cpu=4
Example failed e2e job here.

Additional context

Problem sources:

capsule/e2e/resourcepool_test.go

Line 1148 in 8dbbe3c

Expect(claim.Status.Condition.Message).To(Equal("requested: limits.cpu=2, queued: limits.cpu=4; requested: requests.cpu=2, queued: requests.cpu=4"), "Actual message"+claim.Status.Condition.Message)

[Raj-G07]

@Svarrogh1337 I would like to work on this issue , just for clarification you want to change only what inside the Equal("") , or something else!

[oliverbaehler]

We are unsure if the problem is the test or rather in the reaourepool logic. I suspect its about the order how the resources are printed, because that was quiet hacky to implement. But maybe theres also a value mismatch, which would be more sever.

Part of this issue is to investigate the why

[prometherion]

The root cause is that maps are accessed in random order in Go, making unpredictable.

We should avoid expecting an order, and rather, use a set.String filling it with the sanitized entries and checking all of them are there.

Or, ordering the entries when iterating over the resource field which is a map.

[oliverbaehler]

Thing is we are checking the status text in these tests, so we weither have to not check the string as its unpredictable or something else

[Svarrogh1337]

@Raj-G07 you can go ahead and work on it and have in mind what @oliverbaehler and @prometherion shared.
If you have any questions, don't hesitate to ask.