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

validate-modules for plugins: for callback plugins, type vs. callback_type #71798

Closed
felixfontein opened this issue Sep 17, 2020 · 6 comments
Closed
Labels
affects_2.15 bug This issue/PR relates to a bug. has_pr This issue has an associated PR. support:core This issue/PR relates to code supported by the Ansible Engineering Team. test This PR relates to tests.

Comments

@felixfontein
Copy link
Contributor

SUMMARY

This is not a bug, but a discussion issue for one aspect of #71734 ([WIP] Extend validate-modules to also validate plugins). It provides details on one of the points in ansible/community#560 (comment).

Callback plugins have a type. In the plugin class, it can be set as the class attribute CALLBACK_TYPE.

For documentation, there are two versions:

  1. callback_type: <type>
    callback_type: notification
  2. type: <type>

In ansible/ansible, type is much more common (there's only one callback using callback_type). In community.general, 1/3 of the callback plugins uses callback_type.

I would suggest that we use only one of these two. My personal suggestion would be callback_type, since it is close to the CALLBACK_TYPE attribute of the plugin class. On the other hand, @abadger chose type in the antsibull-docs schemas (https://github.com/ansible-community/antsibull/blob/main/antsibull/schemas/callback.py#L23).

ISSUE TYPE
  • Bug Report
COMPONENT NAME

test/lib/ansible_test/_data/sanity/validate-modules/validate_modules/main.py

ANSIBLE VERSION

2.11

bot_skip

@ansibot
Copy link
Contributor

ansibot commented Sep 17, 2020

Files identified in the description:

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added affects_2.11 bug This issue/PR relates to a bug. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. test This PR relates to tests. labels Sep 17, 2020
@samdoran
Copy link
Contributor

Per discussion today, we would like to standardize on type.

@samdoran samdoran removed the needs_triage Needs a first human triage before being processed. label Sep 22, 2020
rrey pushed a commit to ansible-collections/community.grafana that referenced this issue Oct 4, 2020
@ansibot ansibot added the has_pr This issue has an associated PR. label Jan 23, 2021
@jborean93
Copy link
Contributor

@felixfontein is there still action to be done on this issue?

@felixfontein
Copy link
Contributor Author

I don't think so, it's basically documenting a decision which is now part of the schema of the validate-modules test. I'll close it.

@ansible ansible locked and limited conversation to collaborators Mar 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.15 bug This issue/PR relates to a bug. has_pr This issue has an associated PR. support:core This issue/PR relates to code supported by the Ansible Engineering Team. test This PR relates to tests.
Projects
None yet
Development

No branches or pull requests

5 participants