New commit detected on ManageIQ/manageiq/gaprindashvili:

https://github.com/ManageIQ/manageiq/commit/b8bc7bed2cd1a3fdbd81454cb8e176c7ec5c02d5
commit b8bc7bed2cd1a3fdbd81454cb8e176c7ec5c02d5
Author:     Greg McCullough <gmccullo@redhat.com>
AuthorDate: Thu Apr 19 08:47:41 2018 -0400
Commit:     Greg McCullough <gmccullo@redhat.com>
CommitDate: Thu Apr 19 08:47:41 2018 -0400

    Merge pull request #17280 from d-m-u/adding_lock_to_retire_now

    Add lock to retire_now start
    (cherry picked from commit 2deffa58399461396e3bbd57b93fc744f0c64e88)

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

 app/models/mixins/retirement_mixin.rb | 43 +-
 spec/models/service/retirement_management_spec.rb | 23 +-
 spec/models/vm/retirement_management_spec.rb | 19 +
 3 files changed, 67 insertions(+), 18 deletions(-)

This is difficult to reproduce, but probably the best setup would be: 

1. An environment where there are 4 zones.
2. A Service with a retire_on date of today.

Each of the schedule workers should initiate the Service retirement at the same time, causing the request_service_retire event to be raised 4 times.
You should be able to see the events raised and the service retirement state machine start_retirement Automate method running.
The more zones, the better the odds of reproducing the customer scenario.

Closing this one as it is hard for QE to validate.