failure in k8s task when using a definition list should have better error message

[jmazzitelli]

SUMMARY

Use a list in k8s definition list:

  set_fact:
    my_yaml_files: ["some.yaml", "another.yaml"]

  k8s:
     state: "present"
     namespace: "default"
    definition: |
      {% for mdy in my_yaml_files %}
      ---
      {{ lookup("template", mdy) }}
      ...
      {% endfor %}

If there is a syntax error in one of the templates (or simply that a resource in the list fails to be created), the error message that k8s spits out doesn't tell you WHICH item in the list fails.

ISSUE TYPE

• Bug Report

COMPONENT NAME

k8s

ANSIBLE VERSION

2.9

STEPS TO REPRODUCE

See above.

EXPECTED RESULTS

An error message that better indicates which item in the list failed.
It might also be nice to have the rest of the items processed, but that might break the k8s design. As it is, if you have ANY error in ANY item in the list, the entire list of resources apparently fail to be persisted/created.

ACTUAL RESULTS

You do get an error, but all resources abort (fail to get created) so you aren't sure which item in the list caused the failure.

[jmazzitelli]

cc @fabianvf

[jmazzitelli]

@fabianvf my example might not be exactly what you are looking for (because it really isn't a list that my example pulls in). Feel free to change any of this to get this to what you want :) I think you understand what I was doing though - maybe this isn't exactly what you were thinking I was doing.

[Akasurde]

@jmazzitelli I am not sure if we can tell which definition file failed since we are generating a "big" YAML file using jinja for loop.

I don't have the background for your requirement but I think the helm chart is the way to go forward. Helm chart handles multiple resources.

[jmazzitelli]

I don't have the background for your requirement but I think the helm chart is the way to go forward. Helm chart handles multiple resources.

You are saying re-implement my entire operator (to use helm rather than ansible) to workaround this issue? That's obviously a no-go for me.

@fabianvf thoughts?

[Akasurde]

OK. Will wait for @fabianvf to comment.

[fabianvf]

@Akasurde there shouldn't be any need for a helm chart here, there should be nothing you can do easily with helm that you can't easily do with pure Ansible (if there is we should address that gap).

The k8s module doesn't actually process the single yaml file any different than it would a normal list of resources, it will yaml.load_all the file and then iterate over the resources, sending each one to the API server, so we should be able to easily tell which resource failed to be created. Improving the error reporting when processing multiple items will help this case in addition to more standard ones.

[tima]

Thanks @fabianvf. Any opinions on how to handle an error? Should the module stop processing once a resource operation fails or continue to try more?

[jmazzitelli]

Should the module stop processing once a resource operation fails or continue to try more?

Can you make that configurable? abort_on_error boolean or something? I actually have both use-cases... in one case, I would want to abort immediately and not try the rest... in another use case, I want to try them all even if one fails (I plan on having a ignore_errors:true on that task - these are optional resources that should not fail my operator's reconciliation run if one or more fails to get created).

[abikouo]

Should the module stop processing once a resource operation fails or continue to try more?

Can you make that configurable? abort_on_error boolean or something? I actually have both use-cases... in one case, I would want to abort immediately and not try the rest... in another use case, I want to try them all even if one fails (I plan on having a ignore_errors:true on that task - these are optional resources that should not fail my operator's reconciliation run if one or more fails to get created).

@jmazzitelli I am working on this issue.
as the default behavior now is to abort when one resource creation failed (the validation step is already configurable), the boolean should be continue_on_error with the default value false for backward compatibility

[abikouo]

this has been addressed in the following PR #49