Matt Davis

I wouldn't mind getting some version of this in, but I'd like it to be configurable... Unfortunately with the current API pattern that means yet more constructor kwargs... :(

We should probably also add checks for any 500 errors to see if there's still readable SOAP, and if so, propagate the error message contained inside.

@smapjb That shouldn't be the case- this is a _very_ specific failure to the first request against a brand-new machine (so any Ansible winrm op would fail, not just scan...

We should probably just deprecate that arg, it's somewhat vestigial from before package facts were around...

`apt_key` is kinda on its way out anyway- note that the current module docs show that the underlying utility has been deprecated and that the module is only around for...

Newer versions of Ansible default to native Jinja2, which might make this more feasible- can you try against 2.13+ to see if this is still an issue for you?

Addressed by #78424 - thanks!

The (possible) unintended consequence I was talking about was this: Package A was preinstalled that depends on Package B (an implicitly-installed package). An Ansible task comes along at some point...

Failures during fact gathering around iscsi devices has been made a bit more robust in newer Ansible releases- can you try this with 2,12+ and see if it behaves better?

@MKletz we've kicked this around at a couple meetings, but haven't seen you- stop by one of our IRC meetings if you can.