k8s_scale fixes

[willthames]

SUMMARY

Fix scale wait and add tests

Move wait logic out of raw and into common and use that
logic in scale

Fix a few broken wait condition cases highlighted by scaling
up and down

Move scale-related tests into dedicated test task file

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

k8s_scale

ADDITIONAL INFORMATION

[willthames]

Based on #35 - merge that one first

[codecov]

Codecov Report

Merging #100 into master will decrease coverage by 0.10%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #100      +/-   ##
==========================================
- Coverage   42.98%   42.88%   -0.11%     
==========================================
  Files           3        3              
  Lines         542      541       -1     
  Branches      110      110              
==========================================
- Hits          233      232       -1     
  Misses        266      266              
  Partials       43       43              

Impacted Files	Coverage Δ
...ommunity/kubernetes/plugins/module_utils/common.py	37.93% <0.00%> (-12.76%)	⬇️
...s/community/kubernetes/plugins/module_utils/raw.py	44.51% <0.00%> (+5.65%)	⬆️

---

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 3bdfb47...aa70416. Read the comment docs.

[geerlingguy]

Latest test is giving:

Failed to apply object: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure",
"message":"Service "apply-svc" is invalid: spec.ports[1].nodePort: Forbidden: may not be used when `type` is 'ClusterIP'"

...which is weird, because it seems like type is set to NodePort...?

[willthames]

@geerlingguy the bit where it was failing was in adding a port to an existing service, and also setting NodePort at the same time (I suspect I mis-merged two separate changes at some point) - just need to be consistently all NodePorts or all ClusterIPs. I've changed it to the latter.

[geerlingguy]

Now this is failing with the same thing mentioned in #104 —

    TASK [Check that deployment wait worked] ***************************************
    task path: /home/runner/work/community.kubernetes/community.kubernetes/ansible_collections/community/kubernetes/molecule/default/tasks/waiter.yml:247
fatal: [localhost]: FAILED! => {
    "assertion": "updated_deploy_pods.resources[0].spec.containers[0].image.endswith(\":2\")",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}
    Read vars_file 'vars/main.yml'

[willthames]

Yeah, there's definitely a race condition, not 100% sure on the best course of action - Kubernetes is doing the right thing, the tests are doing the right thing, just perhaps too soon.

I might just have to improve the filters to ignore the unready pod where its container has terminated but the pod is still not in terminating state (that bit is weird)

[geerlingguy]

LGTM on initial review—I like that we're removing net 93 LoC in the python modules and fixing bugs at the same time!

[fabianvf]

👍 looks great, removes a lot of cruft and moves some common logic from raw -> common.

[geerlingguy]

Merging—it also seems to fix the instability with our CI tests, so I can stop getting nightly fail notifications from the scheduled CI run :)