Allow additional provider parameters to be specified on create

[jntullo]

This update will allow individual providers to have more control over the parameters that are allowed when creating a new manager. This will also be a good transition starting point to move a lot of the validation inside of the providers themselves, rather than having it all within the API controller.

As an example, the Azure provider would like users to provide azure_tenant_id, which is not possible under the current API validation. By updating .api_allowed_attributes on the Azure::CloudManager to return azure_tenant_id, users will be allowed to specify that attribute for Azure Cloud Managers.

@miq-bot add_label wip, enhancement
cc: @juliancheal @bronaghs

Dependent on ManageIQ/manageiq#16802

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

[juliancheal]

Is this ready to be un-wipped?

[jntullo]

@juliancheal will unwip when ManageIQ/manageiq#16802 is merged

[cben]

So this allows writing azure_tenant_id but does this also allow reading it back?

https://github.com/juliancheal/manageiq-providers-azure/blob/1394bf82a4/app/models/manageiq/providers/azure/cloud_manager.rb#L21

alias_attribute :azure_tenant_id, :uid_ems

So perhaps it'll get sent back under uid_ems key on read (?)
BTW, why do we need the alias on write rather than telling users to put tenant in uid_ems? Because that's just an implementation detail? If we want to hide it on write, let's also hide it on read IMHO.

In general, providers read/write has various asymmetries (#26), I'd like to reduce not increase them...

[juliancheal]

Good point @cben I'll check it's read as azure_tenant_id too.

The field that the user would know from Azure documentation is tenant_id, but as that clashes with ManageIQ tenants we've had to change what value we store it in.

[bronaghs]

@cben Why do you believe the user cannot read back the azure_tenant_id? Do you mean like this? :

ManageIQ::Providers::Azure::CloudManager.first.azure_tenant_id

[bronaghs]

@jntullo - does the results hash mirror the database columns? Is that why the first hash key is uid_ems and not azure_tenant_id

[jntullo]

@bronaghs yeah, it is all of the physical attributes

[cben]

I meant via API, by GET /API/providers/1

…

On Jan 15, 2018 21:42, "Bronagh Sorota" ***@***.***> wrote: @cben <https://github.com/cben> Why do you believe the user cannot read back the azure_tenant_id? Do you mean like this? : ManageIQ::Providers::Azure::CloudManager.first.azure_tenant_id

[bronaghs]

Ah @cben, thanks for clarifying - I touched on the same point in my review comment above
I, too, think we should read back azure_tenant_id.

[jntullo]

@bronaghs I did some thinking on this and now that I see this is a similar issue in openstack (where keystone_v3_domain_id is an alias of :uid_ems), I am thinking it may be a good idea to consider a serializer for these objects, so that they can get read back the same way. Thoughts? @juliancheal @cben @abellotti

[miq-bot]

Checked commit jntullo@feeaa6c with ruby 2.3.3, rubocop 0.52.0, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 🍰

[abellotti]

LGTM!! Thanks @jntullo for this enhancement. 👍