wait until pod is scheduled

[sbawaska]

when a resource is just applied/installed, all pods may not be scheduled immediately, so be more patient.

closes #31

[codecov[bot]]

Codecov Report

Merging #32 into master will not change coverage. The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #32   +/-   ##
=======================================
  Coverage   84.55%   84.55%           
=======================================
  Files          10       10           
  Lines         408      408           
=======================================
  Hits          345      345           
  Misses         41       41           
  Partials       22       22

Impacted Files	Coverage Δ
pkg/kab/readyness_checker.go	89.47% <100%> (ø)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 5625550...86d61df. Read the comment docs.

[sbawaska]

@glyn To me checking to see if the pod is in a desired state is exact same check kubernetes itself would perform. Since kubernetes uses exponential backoff, I used it too. Would love to hear your thoughts on why linear backoff would be better.

[glyn]

@glyn To me checking to see if the pod is in a desired state is exact same check kubernetes itself would perform. Since kubernetes uses exponential backoff, I used it too. Would love to hear your thoughts on why linear backoff would be better.

@sbawaska It doesn't seem unreasonable to use exponential backoff, but it might reduce responsiveness unnecessarily when it kicks in. I think it's often used to avoid making things worse when problems are caused by overloading, which might be the case here at least some of the time. Let's leave it for now and come back if responsiveness is impacted (in which case we could combine linear backoff with switching to exponential backoff eventually).