Manageiq: Background Jobs will not start until the provider credentials have been validated

[abonas]

When creating a new provider, if its details are saved without pressing "validate" credentials first, its background refresh workers won't start.
It's not intuitive and not clear to user that this is the implication of saving a provider.

as proposed on gitter by @Fryguy, worth to add a clarification message on saving the provider:
"Are you sure you want to save without validating? Background Jobs will not start until the provider credentials have been validated"

@miq-bot add_label ui
cc @dclarizio @pilhuhn

[blomquisg]

@dclarizio how do you feel about this?

[pilhuhn]

cc @Ladas @AparnaKarve As you were just discussing almost the same thing.

[Ladas]

we have a similar issue, right now the creds do not save on validate, that means we can't fix validation and restart worker

But I wasn't aware of that validate button needs to be hit on creation, so seems like a similar issue?

[dclarizio]

@blomquisg @Ladas @pilhuhn @AparnaKarve

Results of the chat discussion seem to be that we should not allow Save button to enable until all required form fields are entered and all end point credentials have been validated. So:

• On each end point tab, if validation is needed, show the tab in red (or somehow indicate the tab needs attention) and display a red message inside the tab area stating "Validation required".
• If relevant form fields (i.e. IP, Host Name, Port, credentials, etc) are changed on the form, this invalidates any validations that have been done, the tabs turn red again with validation required message, and Save is disabled.
• Pressing Validate on an end point tab may take longer due to network/timeout issues, but at least this would be expected, rather than overloading Save to do the validation.
• Save is only enabled if all form fields are valid and all entered credentials have been validated, so pressing Save only has to save the record. Refresh workers should then be able to start successfully.

Assigning this to @AparnaKarve, so please comment with any issues as we will start working on this.

[Ladas]

@dclarizio btw. this will need to be backported, without saving of the validation, we are not able to start again worker with error status.

[dclarizio]

@Ladas when the creds are updated and validated, then when the record is saved, I would expect the model to clear the invalid flag and restart the worker. I'm not sure if we will need a back end change for that, but I don't think it would be the UIs responsibility to actually restart the worker. The record being saved should be enough for the model to realize the worker can be restarted.

[Ladas]

@dclarizio yes, you are right, it's enough to save the record, especially the status of the authentication is the important thing. Then it will just work.

[jrafanie]

All ems based worker runners should be calling ems.authentication_check as part of their boot and exit if the auth is bad. This check will also mark the ems as bad or good based on the result.

Therefore it's only necessary to show the authentication_status for the provider/ems and provide a button to re-check in case of it being bad. Note, there's different values based on the type of "bad".

See example usage of authentication_status

Here's two example of ems based workers checking the auth, marking them as good/bad and exiting if bad:
event_catcher
refresh worker

I hope this helps.

[jrafanie]

Note, the results of authentication_status are capitalized versions of these keys.

Valid
None
Incomplete
Error
Unreachable
Invalid

I believe you want to display the re-check in the case of the latter 3.

[dclarizio]

OK, for all who are following. I think the most important part is to add the Re-check Authentications button, so @AparnaKarve will start working on that and may need some help on the provider back end. This will avoid having to go into edit unless the credentials are actually invalid. The updates to the editor (above) are more of a "nice to have" that we will work on going forward.

[Fryguy]

@dclarizio That sounds great! Be sure that when calling authentication_check from that button that it's done via the queue (i.e. not done in the UI worker). If there isn't an authentication_check_queue method, it can be added.