Open sivel opened 1 year ago
So for (1 i would say just use the 'logging' type, which is not singular, but also I do not think it is required to be, it just needs to capture and make available the data required by the implementer in ways it hooks up to the code waiting for it.
For (2, we can call ansible-config
to get the currently configured callbacks, add the desired plugin to the list and return it in ANSIBLE_CALLBACKS_ENABLED
.
ansible-config dump |grep CALLBACKS_ENABLED
Does this mean that currently if we change the default stdout callback from awx_display in ansible-runner, there are consequences/negative implications of doing so? I am currently working on a project at my org to use a custom stdout plugin with runner.
Does this mean that currently if we change the default stdout callback from awx_display in ansible-runner, there are consequences/negative implications of doing so? I am currently working on a project at my org to use a custom stdout plugin with runner.
I am currently trying to add environemtal vars like "awx_job_id" via custom callback plugin to the json log I receive in logstash. I am not able to make it work. Did you do something similar and made it work? I was wondering if the issue is the execution environment with the awx_display.
Ultimately making
awx_display
be thestdout
callback plugin is rather limiting, and has complex implementation impacts to allow any non-default callback plugin to be specified by the user.It would be more flexible if we can not require this, and allow
awx_display
to be an add on callback.There are some things in core that likely need to change to permit this. A few potential options:
stdout
, that integrators can overwrite.We'll need to research the full capabilities needed of moving this plugin away from being the stdout plugin.
In addition to this: