Add PXE server credential validation endpoint

[lfu]

Depends on ManageIQ/manageiq#21013.

#926

@miq-bot add_label enhancement, kasparov/no

POST /api/pxe_servers
{"action" => "verify_credentials",
 "resource" =>
  {:name => "test", :uri => "smb://tmp/foo", :username => "test", :password => "foo"}
}

RESPONSE
{"results" =>
  [{"success" => true,
    "message" => "Credentials sent for verification",
    "task_id" => "13000000000006",
    "task_href" => "http://localhost:3000/api/tasks/13000000000006"}]
}

[lfu]

@miq-bot cross-repo-tests ManageIQ/manageiq#21013

[agrare]

@lfu if you're re-verifying credentials (e.g. if you edit an existing resource) we don't require the user to enter a password again but instead load it from vmdb if it doesn't exist (e.g. they only change the username or IP).

We do this by passing in data["id"] = id if id here and handling it on the verify_depot_settings side if an "id" is passed.

I don't know if that's something that we want to do on the UI for PxeServers but I expect it probably is and would keep parity with provider authentication verification.

[agrare]

@lfu (or @Fryguy @bdunne) do you need to pass PxeServers a zone? I don't see one in the table right now but with any "local" resource it might not be reachable from every zone.

[bdunne]

That's a good idea

[lfu]

@lfu if you're re-verifying credentials (e.g. if you edit an existing resource) we don't require the user to enter a password again but instead load it from vmdb if it doesn't exist (e.g. they only change the username or IP).

@agrare verify_depot_settings always creates a new instance to verify the settings.

[agrare]

@lfu yes the problem with that is since we don't pull passwords back over the API if the user is editing an existing instance they have to re-type their password even if they don't intend on changing it.

We can handle that in a follow-up if you want but I don't think that's the best user experience.

[Fryguy]

@agrare Do we have a similar pattern for this with provider validation you can point to? I think this probably is big enough that we should fix for this PR.

[Fryguy]

Oh sorry ... didn't realize this was an outdated comment. Is this done then?

[Fryguy]

Mostly asking because I don't see anything that looks up the existing instance on the core side's method - ManageIQ/manageiq#21013

[agrare]

@Fryguy the API now matches the pattern for provider validation, core still doesn't lookup the instance yet not sure if you want that for this PR set or as a follow-up

[Fryguy]

I think we need the core change then. Otherwise, we have a "broken" API in the interim.

[miq-bot]

Checked commit lfu@f9a04ac with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint
2 files checked, 1 offense detected

app/controllers/api/pxe_servers_controller.rb

• ❗ - Line 58, Col 44 - Naming/MethodParameterName - Method parameter must be at least 3 characters long.

[chessbyte]

@miq-bot cross-repo-tests /all

[kbrock]

is this good to go?

[Fryguy]

Looks like we are still waiting on #1017 (comment). This was mainly being introduced for UI changes, and I'm not sure if there's priority on it. @kavyanekkalapu would know better. Otherwise, we can just leave this open until we get back to that screen.

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s)

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[kbrock]

Looks like ManageIQ/manageiq#21013 has been merged.
Does that mean we can merge this one?

If we need changes, I can rebase/fixup.
If it is not a priority, then that is good too

We were held up on #1017 (comment)

the API now matches the pattern for provider validation, core still doesn't lookup the instance yet not sure if you want that for this PR set or as a follow-up

Ah, never mind. I mixed up the dates and thought that PR was merged after Nov 2021, but it was merged before

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s)

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This pull request has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this pull request if these changes are still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).