Embedded Ansible in devel mode

Or, what to do when you just need the embedded ansible role to work in development setup. Taken from https://github.com/ManageIQ/guides/pull/276#issuecomment-538070129.

---

Quick Instructions

1. Start a development server:

   $ bin/rails s

2. Enable the Embedded Ansible role on the settings page

3. From the console, run the following:

   $ bin/rails c
   irb> ManageIQ::Providers::EmbeddedAnsible.seed
   irb> MiqServer.my_server.reload_settings # just incase
   irb> MiqServer.my_server.sync_assigned_roles
   irb> MiqServer.my_server.monitor_server_roles
   irb> MiqRegion.my_region.role_active?('embedded_ansible')
   #=> true

Long Answer (WTF is going on here)

Well, the tl;dr for the "long answer" since bin/rails s doesn't run a MiqServer instance which is in charge of both seeding the EmbeddedAnsible data and setting up server roles.

The methods specifically that are locking you out are found here:

https://github.com/ManageIQ/manageiq-ui-classic/blob/fbd7afa844298d5d7dc2ece8de168eff746c1ba5/app/helpers/application_helper/button/embedded_ansible.rb#L1-L5

Specifically:

• !MiqRegion.my_region.role_active?('embedded_ansible')
• ManageIQ::Providers::EmbeddedAnsible::Provider.count.zero?

Each of those are described below:

Seeding

So seeding for EmbeddedAnsible is located here, and that will get triggered by lib/evm_database.rb here (which is included as part of the [OTHER_SEEDABLE_CLASSES][]). This is triggered on server start by the [MiqServer.start][], so this explains why you didn't see this when running a local server since MiqServer.start is never triggered when doing

$ bin/rails s

So above, I have simulated that by just calling the seed method directly:

ManageIQ::Providers::EmbeddedAnsible.seed

I was initially under the impression that activating the role actually enabled this seeding, but that is I guess not the case. However, I admittedly spent way to much time trying to determine that wasn't the case...

Server roles

So this part also took a bit to figure out...

Again, this is something that is triggered by the MiqServer, and it is part of the monitor_loop:

https://github.com/ManageIQ/manageiq/blob/65e86960ed9f17d3250c23437af28db655a2b633/app/models/miq_server.rb#L342

This does eventually call the role balancing code and activates the needed roles, but it requires using the role data from the "default roles" from the settings, which isn't set here.

This is set and modified via the ops UI, and updates from there eventually trigger this method:

https://github.com/NickLaMuro/manageiq/blob/65e86960ed9f17d3250c23437af28db655a2b633/app/models/miq_server/configuration_management.rb#L9-L14

Which will reload the settings value that has now been updated via the Ops UI. This gets synced to the MiqServer instances as part of the [monitor_workers][] call, which eventually triggers .sync_assigned_roles in [sync_needed?][].

.sync_assigned_roles will eventually call [MiqServer#role=][] to create the AssignedServerRole records to the server, but doesn't activate them.

Note: Up until a little over a week ago, #role= was the only method, but someone (adam) decided to change it to make this explanation even more verbose than it needed to be...

So the MiqServer#monitor_server_roles roles is then in charge of just that, and will activate any of the created roles that need to be activated.

At this point, after these three lines have been called:

MiqServer.my_server.reload_settings # just incase
MiqServer.my_server.sync_assigned_roles
MiqServer.my_server.monitor_server_roles

MiqRegion.my_region.role_active?('embedded_ansible') should now return true and the UI should work as expected.

Should this be much more straight forward in development mode? Yes Do I have an idea how we would go about doing that? No

But hopefully, for @himdel and others, this explanation gives insight into the "why", and we can determine the "how" for the above from that.