Keep track of the server ids where the automate task has been processed.

[lfu]

Support has been asking us for helping them with diagnosing customer issues. Since we have multiple appliances and a task can bounce around from one appliance to the next, they would like to know on which appliance a task ran so that they can hone in on specific logs.

This PR tries to store the different server ids where a task was executed in the "options" hash. Which can then be used for debugging.

Automate tasks can get put back on the queue and picked back up several times during an automate task.
Includes ManageIQ/manageiq-automation_engine#183.

https://bugzilla.redhat.com/show_bug.cgi?id=1535237

@miq-bot assign @gmcculloug
@miq-bot add_label automate

[lfu]

@gmcculloug Anything to update?

[lfu]

@Fryguy @jrafanie @gtanzillo @mkanoor Please review.

[mkanoor]

@lfu
We might be able to use a better name than trace_server_ids. Can we use waypoints https://en.wikipedia.org/wiki/Waypoint.
Since its a journey for a task it can run on different servers and the way points kind of tell you which servers you visited.
Lets check with others which name they prefer

• mark_execution_servers
• mark_waypoint_servers
• record_execution_servers

[lfu]

@mkanoor I like the name mark_execution_servers. Will update the PR with this name.

[jrafanie]

This makes sense. How do we plan to expose this to someone trying to troubleshoot an automate execution? The log collection screen doesn't show ids. Are we planning a way to correlate ids to hostnames/names? We have other methods that might present more user friendly values

from miq_server.rb:

  def format_full_log_msg
    "MiqServer [#{name}] with ID: [#{id}], PID: [#{pid}], GUID: [#{guid}]"
  end

  def format_short_log_msg
    "MiqServer [#{name}] with ID: [#{id}]"
  end

  def friendly_name
    _("EVM Server (%{id})") % {:id => pid}
  end

  def who_am_i
    @who_am_i ||= "#{name} #{my_zone} #{self.class.name} #{id}"
  end

[lfu]

@Fryguy Please review. Are you good with saving the executed server ids into the options hash of MiqRequestTask?

[Fryguy]

My only issue here is the way the .uniq works, and the expectations on the contents of this Array.

For example, if the task executes on server 1, then server 2, then back to server 1, I'm probably mostly concerned about the most recent server, so I'd expect 1 to be the last element of the Array, but...

[1, 2, 1].uniq
# => [1, 2]

So, what are the expected usages of this Array?

[gmcculloug]

The initial usage is to know what servers to collect logs from.

But maybe we do not worry about calling uniq on the array and let it add duplicate IDs. Then the caller can decide how they want to use the data. A find call on the array will only return one instance for each ID and if you only cared about the last server you would be able to do that as well.

With retries waiting for processes to end this could become a long array, but I do not see this being a big issue.

[lfu]

@Fryguy This array is to record the id of servers where the automate task has been processed. So all the logs from these servers would be collected in case of troubleshooting. The order of the ids in the array is not important in this case.

[lfu]

@gmcculloug If a long array is not a concern, we can get rid of calling uniq.

[Fryguy]

@lfu, yes, this approach works for me...I just have a small question on the use of .uniq

[Fryguy]

LGTM

[miq-bot]

Checked commits lfu/manageiq@679623f~...96ab071 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
4 files checked, 0 offenses detected
Everything looks fine. 🍪