Automate Method Support should go over REST API, instead of DRb

[chessbyte]

(Taken and updated from ManageIQ/manageiq-automation_engine#44)

---

Automate currently runs methods by

• starting a DRb server
• spawning the ruby method wrapped in a preamble and postamble, with the preamble starting a DRb client
• client uses service models and helper classes like $evm to communicate with the server

This causes a number of problems and headaches, which may be able to be addressed by moving to a REST API based implementation. Some notable issues:

• DRb requires server side object management so that the server doesn't garbage collect objects in use by the client. This is a huge headache which will just go away with REST.

• Every time we add a new object or method it is automatically exposed via the service models. This couples our database schema to the automate schema and makes upgrades and keeping compatibility difficult. This would instead become an exercise in exposing via the REST API, which in nearly all cases should be done anyway.

• DRb is used to handle interactions with the automate workspace, which is in the server's memory, from the client. For the ansible-based methods we've already created a way to serialize the workspace, store it in the database, and expose it over the REST API via /api/automate_workspaces/GUID. The GUID and an API token can then be given as a parameter to the Ruby method, via preamble, so it can access and update the workspace over the REST API.

• DRb is also used for database interaction. The database interaction that is currently done via service models, can be done completely through the REST API. Ruby methods can use the manageiq-api-client gem. Then the $evm.vmdb can just be a front for accessing those objects from the manageiq-api-client gem. We could even deprecate $evm.vmdb in favor of having the automate methods use the normal manageiq-api-client gem directly.

  For example, currently $evm.vmdb["vm", 21] returns a MiqAeServiceVmVmware instance for VM 21. Instead, with the manageiq-api-client, that could return a ManageIQ::API::Client::Vm instance for VM 21

  With this in place, I think the entirety of the service models just goes away

• DRb is also used for built-in methods (like send_email). This can be handled by exposing them from the REST API, and passing the workspace guid from the method as a parameter to the REST API. These may need some sort of system-only access rules, but then again, maybe not.

[kbrock]

See ManageIQ/manageiq-automation_engine#44

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This issue has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this issue if this issue is still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[Fryguy]

Leaving this closed in favor of the new Workflows engine, so I'm also removing from Roadmap