Adding options_description class method to base_manager

[enoodle]

This is a metadata function that should return the description of the data that is stored in the options field (added in ManageIQ/manageiq-schema#23)

requested here: ManageIQ/manageiq-api#3 (comment)

[durandom]

straightforward.

So, from looking at the PRs provider_settings will return a description what to expect in options ?
Is provider_settings already used somewhere? If not, I'd rather call it options_description to make it a) more related to the options field and b) express that it only contains a description.
It would be also great to see an example in either a spec or a method comment or the git commit msg

[enoodle]

@durandom

I'd rather call it options_description

I only used it in ManageIQ/manageiq-providers-kubernetes#45, and ManageIQ/manageiq-api#3. I can change it in both places.

[durandom]

Oh, so there are already proxy_settings and advanced_settings.

If thats only used in the kubernetes provider currently, I'd really rename that now before it spreads to other providers.

For the ansible tower credentials we've put the description into constants here

@jameswnl wdyt on naming those methods?

[enoodle]

@durandom I made this change in all the places that used this function.

[jameswnl]

How about using same convention as the ansible options? as @durandom pointed out? https://github.com/ManageIQ/manageiq-providers-ansible_tower/blob/479dd815e1969044f20082adb21fbda84da1253d/app/models/manageiq/providers/ansible_tower/shared/automation_manager/network_credential.rb

[durandom]

@jameswnl @jntullo could you point out how the API and UI accesses the option descriptions? I'm more a fan of having actual methods than accessing constants. But we should indeed align the approaches as long as we only have ansible and kubernetes using this.

[jameswnl]

API responds to OPTIONS call and return API_OPTIONS of credentials. See the spec here

@jntullo can correct/provide more on this

[durandom]

ok, so what do you think of streamlining this via a options_description method? Or some better name?

roping in @imtayadeway as well

[enoodle]

@durandom If you were asking me then I think options_description is a fitting name for this function.

[enoodle]

ping @durandom @imtayadeway @jameswnl do we have a decision? Do we want it in a constant or a function?

[jntullo]

@enoodle a function seems fine to me.

[enoodle]

Then we can merge this and ManageIQ/manageiq-providers-kubernetes#91 to proceed with ManageIQ/manageiq-api#3

[durandom]

I think you'll want to remove the yarn.lock file.
Also, either in a comment above the method I would shortly point out what it's used for. I know that we dont do this a lot, but it's never too late to start.
At least for those base methods in base managers which are supposed to be overwritten

[enoodle]

@durandom PTAL

[miq-bot]

Checked commit enoodle@b7aa783 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
1 file checked, 0 offenses detected
Everything looks fine. 🍰

[durandom]

@miq-bot assign @agrare
@agrare pls merge once green