Re-Add API_OPTIONS to EmbeddedAnsible credentials

[NickLaMuro]

Removed as part of the ansible-runner effort, but added back manually now (instead of inheriting from manageiq-providers-ansible_tower).

This only allows the UI to display and insert credentials, but it does not implement them when using runner.

Unsure if this deservse a [WIP] label. When testing this on an appliance, it seems like adding a credential will make the API request, but the worker doesn't seem to process anything and produce a result. Unsure if this deserves to be fixed here or we can fix in a later PR.

Before

After

Steps for Testing/QA

To confirm this now works, with this code in place:

1. Go to "Anisble > Automation > Credentials"
2. Click "Configure > Add New Credential"
3. A bunch of options should be available, and you should be able to create/save a new credential record

But, as mentioned above, doesn't seem to create records anywhere so unsure if we should be merging this as is or fix other things as well before doing so.

[NickLaMuro]

Ping @Fryguy @carbonin

[NickLaMuro]

Welp... I guess I have to align some hashes... "burb"...

[carbonin]

I think you can stick with WIP and continue with getting credentials CRUD in place unless having these makes some significant improvement in the meantime.

[NickLaMuro]

@carbonin okay. I was considering just trying to push things into master smaller at a faster rate, but I can get behind that workflow as well.

[miq-bot]

Checked commit NickLaMuro@7dfbba5 with ruby 2.3.3, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
11 files checked, 0 offenses detected
Everything looks fine. 🍰

[carbonin]

What does "This only allows the UI to display and insert credentials" and "it seems like adding a credential will make the API request, but the worker doesn't seem to process anything" mean together? What is the actual end result of this PR? I was assuming that a new credential added after this change still wouldn't get displayed in the UI ... right?

Maybe if we make this PR create the record in Authentications and relate it to the manager, but without the actual credential data (essentially what we pull in inventory) then we can get something displayed even if it wont pass that data to the playbook.

[NickLaMuro]

What does "This only allows the UI to display and insert credentials"... mean...

So the UI actually does a fetch to OPTIONS /api/authentications:

• Api::AuthenticationsController#options
• Api::AuthenticationsController#build_additional_fields

to basically generate the forms dynamically from it (updated the PR description, so see above). This basically just loops over the API_OPTIONS constant in the Authentication model:

manageiq/app/models/authentication.rb

Lines 136 to 142 in f812391

	def self.build_credential_options
	CREDENTIAL_TYPES.each_with_object({}) do |(k, v), hash|
	hash[k] = v.constantize.descendants.each_with_object({}) do |klass, fields|
	fields[klass.name] = klass::API_OPTIONS if defined? klass::API_OPTIONS
	end
	end
	end

And if you want to see what they look like, you can take a look at this gist I put together:

https://gist.github.com/NickLaMuro/bcd6a14652e74ca47abeba7d65d4b4cb

(sorry the pics are zoomed in...)

But as you can see, they are dynamically generated, but are all there with just these changes.

---

and "it seems like adding a credential will make the API request, but the worker doesn't seem to process anything" mean...

So what is weird about this is, as shown in the gist above, you can enter credentials just fine:

And it even displays as if it was sucessfull:

You end up with a result of:

{"results":[{"success":false,"message":"type not currently supported"}]}

(and that is a 200 status code it returns)

---

---

So to the meat of your questions:

• ...mean together?
• What is the actual end result of this PR?
• I was assuming that a new credential added after this change still wouldn't get displayed in the UI ... right?

This basically "un-breaks" the UI display issues, but doesn't currently implement them (it seems). I knew as part of pushing #18854 that we didn't have credentials functioning that I would be circling back as my next effort. And what I am doing here is simply taking a carbon copy of what is in manageiq-providers-ansible_tower:

• ansible_tower/shared/automation_manager/amazon_credential.rb
• ansible_tower/shared/automation_manager/azure_credential.rb
• ansible_tower/shared/automation_manager/google_credential.rb

and re-introducing it back here (minus the TOWER_KIND variable since that seemed pointless).

I plan on doing a PR for each of these individually from here on out to make sure they then work with ansible_runner, but I think doing that all in one PR is a little much.

That said, getting them just to save might be worth doing that here since that should apply to all of the record types... but I think this a lot to digest as it is, so let me know what you think (hopefully this helps).

[carbonin]

Thanks for the explanation @NickLaMuro that makes sense to me. In that case I agree that we can merge this now because it would allow us to model and deal with the different credential types one by one or simultaneously. Additionally I think this may un-break the UI specs.

[himdel]

Confirming this fixes the travis failure! 👍

(And the ansible credentials textual summary screen shows

Username |  
Password |  
Private key |  
Private key passphrase |  
Privilege Escalation |  
Privilege Escalation Username |  
Privilege Escalation Password |

(all empty, but present and no error).

Thanks! 👍