Validate cloud credentials on the queue

[jntullo]

### This is very WIP

This PR is for a BZ related to provider validation not occurring in the specified zone and is related to the closed PR ManageIQ/manageiq#4869 that began to work on validating credentials in the queue (I stole a bit of it, thanks @agrare!)

I started to address some of the concerns from @Fryguy's comment by doing the following:

• Getting rid of the temporary EMS
• Calling the raw_connect class method

There are still a couple of things that need to be done for this to work completely:
* raw_connect for amazon and vmware need to be modified slightly to actually validate / not just pass back a connection (have been playing around with this locally to test this PR)
* need to encrypt the credentials before putting into the queue
* write specs
* fix whatever I inevitably broke 😛
Before I continue down this 🐰 hole, I wanted to start a discussion with this PR to see if there are other ideas and/or concerns about this approach.

cc: @jrafanie @blomquisg

[jrafanie]

@jntullo Is this only for "new" providers? I think so, but am just asking because authentication_check not only checks the creds work but also marks the authentication record as valid... so calling authenticaton_check in the UI on an existing record will update the check mark for the authentication status. If this is only new providers, which I think it is, then all is good.

I like this approach. The more we can do async out of the UI workers, the less junk we need to load in them and bloat these processes.

[Fryguy]

and, decrypt them (likely create a different class method on ems that will decrypt and then call raw_connect with the decrypted credentials)

I think you can still have the one method if you use MiqPassword.try_decrypt, that way the caller can pass encrypted or unencrypted, and it will just work.

[djberg96]

Looks like a good opportunity for case/when. Also, should there be an "else" condition?

[djberg96]

You should be able to clean it up a bit like so:

case ems
when ManageIQ::Providers::Openstack::CloudManager
  # stuff
when ManageIQ::Providers::Amazon::CloudManager
  # stuff
end

And so on. Ruby uses === under the hood.

[jntullo]

@djberg96 there was something up with my environment when this was WIP. even through the console, comparing ManageIQ::Providers::Openstack::CloudManager === ManageIQ::Providers::Openstack::CloudManager was returning false. Not sure what eventually happened to fix it.

[djberg96]

@jntullo hmm...well, if the specs are passing and whatever local UAT you're doing works, it should be fine.

[jntullo]

Note: There is a separate BZ involving infra providers, so I will be creating a separate PR for those because it will involve more PRs to different provider repos. This is cloud only.

@miq-bot remove_label wip

[jntullo]

@miq-bot add_label wip

[dclarizio]

@jntullo is this for validation from a cloud provider add/edit form? If so, the UI is waiting (synchronously) on the response from validation before it will enable the Save button. Unless we change the front end, I think this is a synchronous UI task (i.e. the UI is blocked until done). Normally, when the UI code puts a task on the queue, we use a "wait_for_task" method that allows the UI to check occasionally to see if the task is finished, thus freeing up the UI thread. Should we be changing the front end code to use that implementation?

Adding @AparnaKarve as she is more familiar with how this all works.

[AparnaKarve]

@jntullo Can you look up some examples of initiate_wait_for_task to check if that could be used instead of all that logic in queue_authentication_check?

And if not, do you think most of the code in queue_authentication_check should reside in the core repo, in the authentication_mixin?

[AparnaKarve]

(Not sure how to tell about that - would it be outside of the "default" zone?)

@jntullo That would be my best guess too.
Although, the BZ also talks about a "UI role" enabled for a Provider zone as a workaround which makes the validation work.
So I think the check if validation needs to be performed as a realtime operation or as a queued operation should be based on if the UI role is enabled.

I did a bit of digging around and found that session[:selected_roles] contains all the selected roles. So if user_interface exists in session[:selected_roles], then we go ahead with the default realtime validation, otherwise we do the queued validation.

[miq-bot]

Checked commits jntullo/manageiq-ui-classic@252f251~...3a76c63 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
2 files checked, 0 offenses detected
Everything looks fine. 🍰

[h-kataria]

@jntullo we always call realtime_authentication_check when editing existing provider, wondering if we need to check for session[:selected_roles].try(:include?, 'user_interface') here as well

[jntullo]

@h-kataria hm, I am not sure if we need it here because the zone isn't considered with realtime_authentication_check

[h-kataria]

other than that one concern in update_ems_button_validate method, changes look good to me, @AparnaKarve do you know if it's ok to always call realtime_authentication_check when editing exiting EMS

[AparnaKarve]

do you know if it's ok to always call realtime_authentication_check when editing exiting EMS

@h-kataria I do not know the answer to that.
But I would say, let's leave this as-is for now.
I think validating on the queue should be done under very specific conditions, and on a case-by-case basis.
If the need does arise in the future to do queued validation while editing an EMS, we can always add that very easily, now that the groundwork has been laid here.

[h-kataria]

@jntullo fine/yes ?

[jntullo]

@miq-bot add_label fine/no