<h5 dir="auto">ISSUE TYPE</h5>
<p dir="auto">Feature Idea</p>
<h5 dir="auto">COMPONENT NAME</h5>
<p dir="auto">core</p>
<h5 dir="auto">ANSIBLE VERSION</h5>
<p dir="auto">2.2</p>
<h5 dir="auto">CONFIGURATION</h5>
<h5 dir="auto">OS / ENVIRONMENT</h5>
<h5 dir="auto">SUMMARY</h5>
<p dir="auto">The idea would be to add notes to very specific tasks that are presented to the operator during a playbook run in a specific color.<br>
In operational environments it would be useful to notify the operator that a specific task may do something unexpected (e.g. a change is reported, but this is related to a migration or ongoing development). Usually operations is fully aware of what changes a specific release entails, and so the output matches exactly with their expectations.<br>
But from time to time changes may be induced that are unexpected or unrelated to the release. This could be related to changes (moving things around, module development, ongoing work, etc.) and in these cases it would be useful to make the operator aware.<br>
Output could be as simple as:</p>
<div class="highlight highlight-source-yaml notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="    note: Ignore below changes caused by reorganizing codebase, see change request 1234"><pre class="notranslate">    <span class="pl-ent">note</span>: <span class="pl-s">Ignore below changes caused by reorganizing codebase, see change request 1234</span></pre></div>
<p dir="auto">or:</p>
<div class="highlight highlight-source-yaml notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="    note: FIXME - below errors are suppressed, see ticket 1234, Network team is investigating real culprit"><pre class="notranslate">    <span class="pl-ent">note</span>: <span class="pl-s">FIXME - below errors are suppressed, see ticket 1234, Network team is investigating real culprit</span></pre></div>
<p dir="auto">The real benefit of such a mechanism is that it can use specific colors (e.g. purple) for notes during run so that they are easy to interpret and ensures the operator is aware. We currently use the name-property for this, however this is often missed and makes it harder during maintenance windows to validate.</p>
<h5 dir="auto">STEPS TO REPRODUCE</h5>
<h5 dir="auto">EXPECTED RESULTS</h5>
<h5 dir="auto">ACTUAL RESULTS</h5>
<h5 dir="auto">ISSUE TYPE</h5>
<ul dir="auto">
<li>Feature Idea</li>
</ul>
<h5 dir="auto">COMPONENT NAME</h5>
<p dir="auto">task keywords</p>
<h5 dir="auto">ANSIBLE VERSION</h5>
<p dir="auto">N/A</p>
<h5 dir="auto">SUMMARY</h5>
<p dir="auto">Even tho one can have comment blocks in yaml by commenting, I think it would be nice<br>
to more tightly integrate comments, so suggesting the following:</p>
<p dir="auto">setting: <code class="notranslate">display_comments: true</code></p>
<p dir="auto">task:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="- name: install foo
  apt: pkg=foo
  comment: |-
    install foo early to allow foo to run checks before
    installing the rest of our dependencies"><pre class="notranslate"><code class="notranslate">- name: install foo
  apt: pkg=foo
  comment: |-
    install foo early to allow foo to run checks before
    installing the rest of our dependencies
</code></pre></div>
<p dir="auto">I would suggest that comment could also be run as a task itself:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="- comment: |-
    notify restart handler because
    of some issue or whatever
  changed_when: true
  notify: restart"><pre class="notranslate"><code class="notranslate">- comment: |-
    notify restart handler because
    of some issue or whatever
  changed_when: true
  notify: restart
</code></pre></div>