14:59:14 <bcoca> #startmeeting ansible core public irc meeting
14:59:14 <zodbot> Meeting started Thu Oct  8 14:59:14 2020 UTC.
14:59:14 <zodbot> This meeting is logged and archived in a public location.
14:59:14 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:14 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
14:59:40 <felixfontein> o/
15:00:11 <yoctozepto> o/
15:00:56 <bcoca> #topic ansible/ansible#71118
15:01:29 <bcoca> yoctozepto: i would say 'no' to this, handler notification is based on 'task result' not 'item result'
15:01:38 <felixfontein> https://github.com/ansible/ansible/pull/71118
15:01:39 <bcoca> an item can add to the list of notified handlers
15:02:16 <bcoca> if you dont want to add to the list, you can add that to the notify expression to avoid that specific item, based on any condition, including per item change
15:02:52 <yoctozepto> how so?
15:03:13 <yoctozepto> we loop over several services to check if they need a restart
15:03:27 <yoctozepto> presumably need to notify only the changed service
15:03:32 <yoctozepto> but they all get notified instead
15:03:39 <yoctozepto> because all iterations get the trigger
15:03:43 <yoctozepto> if any one does
15:03:50 <bcoca> what if you mark the general task failed?
15:04:13 <yoctozepto> why would I want to fail the task?
15:04:51 <bcoca> you might not want to, but it fails, host gets taken out of active list, then now notifications for 'non hosts' are in queue for handlers
15:05:17 <bcoca> there is a reason the 'handler notification' happens at task level, since most of the things that it requires to function are at that level
15:05:32 <bcoca> yoiu have a specific use case that this would work for, but it breaks many others
15:05:52 <yoctozepto> I see
15:06:23 <yoctozepto> any recommendation how to work around the issue we have? looped handlers are pretty limited now...
15:06:25 <bcoca> as for populating the 'notify list' that is fine if it happens per item, since we only require it at the end of taks when we decide to notify or not
15:06:39 <bcoca> looped handlers or notifying from looped task?
15:06:43 <bcoca> those are diff things
15:07:07 <yoctozepto> looped notifies*
15:07:21 <yoctozepto> (I shortcircuited)
15:07:25 <bcoca> not really seeing the limit, just dont add the handler to list on a condition
15:08:31 <yoctozepto> https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles/nova/tasks/check-containers.yml
15:09:13 <yoctozepto> I couldn't figure out how to amend that except by involving include_task indirection which induces a performance penalty
15:10:10 <bcoca> notify: [ "{{ results is changed|ternary('Restart  ' ~ item.key ~ ' container',  None) }}" ]
15:10:16 <bcoca> ^ or similar
15:11:41 <yoctozepto> oh, I'll give it a try then!
15:11:49 <yoctozepto> I've never seen it used like this before tbh
15:12:52 <bcoca> you can even skip the [] i just added in case you wanted to do several items per loop
15:13:12 <bcoca> notify: "{{ results is changed|ternary('Restart  ' ~ item.key ~ ' container',  None) }}"  should work just as well
15:13:30 <bcoca> since any 'list' will take a string as a 'list of one'
15:13:51 <bcoca> just careful with , cause then it will be 'comma separated string' and split on that
15:14:13 <yoctozepto> thank you, makes sense
15:14:25 <yoctozepto> <still better than powershell quirks>
15:14:29 <bcoca> anything else?
15:14:33 <bcoca> lol
15:14:48 <yoctozepto> not from me, I'll try your hint and let you know in the PR
15:19:10 <bcoca> #topic  open floor
15:24:16 <yoctozepto> bcoca: it doesn't seem to like it though
15:24:21 <yoctozepto> I get "The 'changed' test expects a dictionary"
15:26:13 <bcoca> you might need to use results list and item index
15:26:36 <bcoca> registered vars get 'tricky' when used inside loop, there should be some examples of use in 'when' clauses
15:27:24 <yoctozepto> oh, right, indexing right away
15:37:45 <yoctozepto> bcoca: nope, it does not see the registered results at all in this scope :-(
15:37:59 <yoctozepto> the same message is if I try to check total gibberish
15:39:18 <shertel> can you share a gist of what you're doing?
15:39:23 <bcoca> i'll need to look into that, but it is possible to get inline results and/or tailor the list
15:39:35 <bcoca> shertel: https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles/nova/tasks/check-containers.yml
15:41:04 <yoctozepto> http://paste.openstack.org/show/798873/
15:41:12 <yoctozepto> I'll tried the above without indexing yet ^
15:41:26 <yoctozepto> but this would normally be a dictionary
15:41:36 <yoctozepto> containing the global 'changed' value
15:41:50 <yoctozepto> but it seems the 'register' has not happened yet
15:41:58 <bcoca> i'll need to look into that, but it is possible to get inline results and/or tailor the list http://paste.debian.net/1166362/
15:42:21 <bcoca> register does happen, but you have to keep in mind how its evaluated, so default is always needed at one point to avoikd initial errors
15:43:16 <bcoca> though might be better to just use map and construct the list at the end when you ahve .results
15:43:57 <yoctozepto> ah, ok, let's see
15:44:22 <bcoca> '{{ "results" in r|ternary(r.results|map(...) , omit)}}'
15:44:41 <bcoca> might still need default there, cause of how ternary works
15:44:51 <bcoca> if/else syntax might be better in this case
15:49:12 <yoctozepto> |default({}) resulted in no handlers getting triggered, possibly because it had to always default to {}
15:50:52 <yoctozepto> i'll try the var indirection
15:57:08 <bcoca> ^ hmm, my test does get them triggered
15:57:21 <bcoca> in any case, we can continue this elsewhere, goint to close meeting for now
15:57:24 <bcoca> #endmeeting