Skip to content
This repository has been archived by the owner on Jun 13, 2024. It is now read-only.

k8s_info with wait option returns immediately when resource doesn't exist #344

Closed
hojerst opened this issue Jan 12, 2021 · 3 comments
Closed
Assignees
Labels
priority/medium type/bug Something isn't working

Comments

@hojerst
Copy link

hojerst commented Jan 12, 2021

SUMMARY

k8s_info with the wait option does return immediately when no object is found.

From the example in the

ISSUE TYPE
  • Bug Report
COMPONENT NAME

community.kubernetes.k8s_info (in collection v1.1.1)

ANSIBLE VERSION
ansible 2.9.13
  config file = /Users/hojerst/.ansible.cfg
  configured module search path = ['/Users/hojerst/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/hojerst/devel/.direnv/python-3.9.0/lib/python3.9/site-packages/ansible
  executable location = /Users/hojerst/devel/.direnv/python-3.9.0/bin/ansible
  python version = 3.9.0 (default, Nov 28 2020, 00:47:30) [Clang 12.0.0 (clang-1200.0.32.27)]
CONFIGURATION
(none)
OS / ENVIRONMENT
STEPS TO REPRODUCE

run the example from the documentation without a object "pod/pod-not-yet-created"

- name: Wait till the Object is created
  community.kubernetes.k8s_info:
    kind: Pod
    wait: yes
    name: pod-not-yet-created
    namespace: default
    wait_sleep: 10
    wait_timeout: 360
EXPECTED RESULTS

I'm expecting that the module waits for up to 360 seconds until the resource "pod/pod-not-yet-created" is in the desired state (Running for Pods).

ACTUAL RESULTS

The module returns immediately without any waiting if the resource is not yet created. This makes the module unusable when the resources are indirectly created by other resources. e.g. a pod which is created by a deployment (or a pod created by a operator)

(no error text output, but this is the "register: result" json object:

{
    "changed": false,
    "failed": false,
    "resources": []
}
@hojerst hojerst changed the title k8s_info with wait option returns immediatly when resource doesn't exist k8s_info with wait option returns immediatley when resource doesn't exist Jan 12, 2021
@hojerst hojerst changed the title k8s_info with wait option returns immediatley when resource doesn't exist k8s_info with wait option returns immediately when resource doesn't exist Jan 12, 2021
@gravesm
Copy link
Member

gravesm commented Jan 15, 2021

@hojerst Thank you for reporting this. I'll take a look.

@gravesm gravesm self-assigned this Jan 15, 2021
@tima tima added verified The issue is reproduced priority/medium type/bug Something isn't working and removed verified The issue is reproduced labels Jan 18, 2021
@gravesm
Copy link
Member

gravesm commented Feb 1, 2021

@tima @Akasurde Thinking about this and I'm not actually sure what the behavior should be. In the case of a specific object as described here--we're given a name, for example--we can wait until the object is created or wait_timeout, whichever comes first. If we are given a less specific query, like listing all the pods in a namespace, for example:

k8s_info:
  kind: Pod
  namespace: foo
  wait: true
  wait_timeout: 180

the only way that's ever satisfied is to always wait the full timeout period.

@hojerst
Copy link
Author

hojerst commented Feb 1, 2021

imho there are two sane algorithms which might work in this case:

  1. query once and then check/wait for all resulting items to reach the desired condition (which seems to be implemented right now)
  2. query continuously (on every iteration) and then check if the desired condition is reached

maybe this can be switched by parameter which defaults to the current implementation. (or use a "magic default" depending if "name" is specified)

This should make this module usable for two usecases:

  • wait for a specific resource to reach the desired state (as intended by me when I created the issue)
  • wait for all currently existing resources matching a query to reach the desired state (which seems to be the current implementation)

Which ever implementation is used, I think the documentation needs to be clear about the implications. As both scenarios might be needed in plays.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority/medium type/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants