Add a common validate_credentials API and method for getting all provider create params

[agrare]

This changes validate_credentials_task from calling raw_connect with
different args for every provider to call a common validate_credentials
method that will be implemented for each provider.

It also adds a top-level method for retrieving each provider's
json-schema create params so that the UI can use data-driven-forms and
build the validate_credentials_task args generically rather than having
to have a case for each provider.

Related: ManageIQ/manageiq-providers-amazon#551

#18818

[agrare]

cc @skateman @Hyperkid123

[agrare]

Sample output:

>> ExtManagementSystem.provider_create_params
=> {"ManageIQ::Providers::Amazon::CloudManager"=>{:title=>"Configure AWS", :fields=>[{:component=>"text-field", :name=>"role", :type=>"hidden", :initialValue=>"ec2"}, {:component=>"text-field", :name=>"region", :label=>"Region"}, {:component=>"text-field", :name=>"ec2_username", :label=>"Access Key"}, {:component=>"text-field", :name=>"ec2_password", :label=>"Secret Key", :type=>"password"}]}}

And the expected payload for AWS's validate_credentials method would look like:

{
  "region" => "",
  "endpoints" => {
    "ec2" => {
      "access_key" => "",
      "secret_access_key" => "",
    }
  }
}

[agrare]

I'm going to drop the change to validate_credentials_task for now so that this can be merged without having to coordinate everything perfectly

[miq-bot]

Checked commit agrare@99155de with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 0 offenses detected
Everything looks fine. ⭐

[agrare]

@skateman @Hyperkid123 @martinpovolny can you review this and ManageIQ/manageiq-providers-amazon#551

[skateman]

I'm okay with this, but could this be used for multiple auth types in a single form? Sometimes we have multiple tabs for providers where you can set different credentials for C&U or something else.

[Hyperkid123]

@skateman assuming the tab has same fields it can be used. We can add prefixes likes default, ssh etc. In the UI based on the tabs we know the form should contain. Alternatively we can add this definition here.

[Hyperkid123]

@agrare is there way to unify the field output names and the expected payload fo the validation endpoint? Frankly this does not really help us. Yes we know how many fields the validation needs but we still have to rename them (by hard coding it in UI) in order to match the expected structure in the validation endpoint.

Based on the expected validation input:

{
  "region" => "",
  "endpoints" => {
    "ec2" => {
      "access_key" => "",
      "secret_access_key" => "",
    }
  }
}

the field names should look like this:

region: "region",
ec2_username: "endpoints.ec2.access_key"
ec2_secret_access_key: "endpoints.ec2.secret_access_key"

[skateman]

@Hyperkid123 the question was more towards the backend being able to handle it than the UI being able to render it...

[agrare]

Since this only has one I simplified it so not need the endpoints array, but if you'd rather keep it consistent then yeah I can go back to having multiple endpoints possible here

[skateman]

@agrare this is not my call, depends on what @Hyperkid123 wants for other providers where we have multiple endpoints...

[Hyperkid123]

I would like to avoid having another switch cases based on provider type. I would rather have just one data structure we can just take and use it directly without additional changes everywhere.

[agrare]

@Hyperkid123 done