Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an error message if a pkg cannot be removed, fixes #35672 #40723

Merged
merged 1 commit into from
Sep 13, 2018

Conversation

kustodian
Copy link
Contributor

SUMMARY

When yum cannot remove a package it fails, but the message why the module failed isn't obvious. This adds an error return field which prints exactly which package couldn't be removed.
This PR is a fix for #35672.

ISSUE TYPE
  • Bugfix Pull Request
COMPONENT NAME

yum

ANSIBLE VERSION
ansible 2.6.0dev0

@ansibot
Copy link
Contributor

ansibot commented May 25, 2018

@ansibot ansibot added affects_2.6 This issue/PR affects Ansible v2.6 bug This issue/PR relates to a bug. core_review In order to be merged, this PR must follow the core review workflow. module This issue/PR relates to a module. needs_triage Needs a first human triage before being processed. owner_pr This PR is made by the module's maintainer. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels May 25, 2018
# Return a special 'error' field so it's obvious to the user
# why yum failed and which package couldn't be removed. More
# details: https://github.com/ansible/ansible/issues/35672
res['error'] = "Package '%s' couldn't be removed!" % pkg
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be better for consistency to append it to res['msg'] rather than creating a new key, since we use msg for errors in the module?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it, but in this situation the msg looks like this:

Skipping the running kernel: kernel-3.10.0-693.21.1.el7.x86_64

Which isn't that obvious tbh and if I appended my message it would be easy to miss it. I would leave msg to the yum output.

Also yum module is all over the place regarding the return keys, it would really be nice if we made it consistent and also add the docs about the return keys. I could probably provide some proposal before any work is done on it if you are interested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong feelings about this really but I guess my concern was that with this we could end up with having error messages in both msg and error at the same time which seems little confusing to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having said that we could do this (add error) for now and do cleanup for the whole module (including documenting the return keys) later.

Copy link
Member

@bcoca bcoca Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it is an error, use fail_json, otherwise it is a warning, which module.warn() can take care of

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bcoca I don't understand what you are saying. We are using fail_json, it's in the next line. This will just make sure all the fields which were set before are also returned.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then that should be the msg= to fail_json, the error key is not a good choice here, i could see a 'failed_pkgs' = [ list of failed] as an additional key, but error seems to be part of a standard that does not exist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with @bcoca here, I would like to see that land in msg

@ansibot ansibot removed the needs_triage Needs a first human triage before being processed. label May 25, 2018
@ansibot ansibot added the stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. label Jun 2, 2018
@kustodian kustodian force-pushed the yum-return-error-cannot-remove-pkg branch from b5b8d22 to 5c80778 Compare August 14, 2018 10:44
@ansibot ansibot removed the stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. label Aug 14, 2018
@kustodian
Copy link
Contributor Author

As requested I set the error message to be returned inside the msg key, so let's get this merged :)

@ansibot
Copy link
Contributor

ansibot commented Aug 22, 2018

@ansibot ansibot added needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. and removed core_review In order to be merged, this PR must follow the core review workflow. labels Aug 22, 2018
@maxamillion
Copy link
Contributor

@kustodian please rebase and resolve the current conflict, thank you :)

@kustodian kustodian force-pushed the yum-return-error-cannot-remove-pkg branch from 5c80778 to 02c1994 Compare September 12, 2018 19:30
@kustodian
Copy link
Contributor Author

@maxamillion done.

@ansibot ansibot removed the needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html label Sep 12, 2018
@ansibot ansibot added core_review In order to be merged, this PR must follow the core review workflow. and removed needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. labels Sep 12, 2018
@maxamillion
Copy link
Contributor

rebuild_merge

@maxamillion
Copy link
Contributor

@kustodian thank you! Sorry about the churn on the code. I'd like to continue to do more incremental clean up now that the major refactor is done but hopefully won't be doing anything that big again. Anyways, thank you again!

@ansibot ansibot merged commit 8d8df46 into ansible:devel Sep 13, 2018
@ansible ansible locked and limited conversation to collaborators Jul 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.6 This issue/PR affects Ansible v2.6 bug This issue/PR relates to a bug. core_review In order to be merged, this PR must follow the core review workflow. module This issue/PR relates to a module. owner_pr This PR is made by the module's maintainer. small_patch support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants