-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VM details page blocked by RHEV API call #1449
Labels
Comments
@matobet 'matobet' is an invalid assignee, ignoring... |
based on the label on the PR where this api call was introduced ManageIQ/manageiq-providers-ovirt#3 it seems that indeed this has been backported to Fine |
matobet
added a commit
to matobet/manageiq-providers-ovirt
that referenced
this issue
May 29, 2017
When called from UI context (i.e. an appliance with only UI role) the provider model may not see the actual RHEV instance (by not having the ems_operations role). This may be a problem in complex production environments so here we do the safe fallback - when the version is nil we mark the import as not supported. Fixes ManageIQ/manageiq-ui-classic#1449
matobet
added a commit
to matobet/manageiq-providers-ovirt
that referenced
this issue
May 31, 2017
When called from UI context (i.e. an appliance with only UI role) the provider model may not see the actual RHEV instance (by not having the ems_operations role). This may be a problem in complex production environments so here we do the safe fallback - when the version is nil we mark the import as not supported. Fixes ManageIQ/manageiq-ui-classic#1449
matobet
added a commit
to matobet/manageiq-providers-ovirt
that referenced
this issue
Jun 1, 2017
When called from UI context (i.e. an appliance with only UI role) the provider model may not see the actual RHEV instance (by not having the ems_operations role). This may be a problem in complex production environments so here we do the safe fallback - when the version is nil we mark the import as not supported. Fixes ManageIQ/manageiq-ui-classic#1449
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
in
1764cc9#diff-a3d6cbf44d730830aac9f86ec31df929R10
the
ApplicationHelper::Button::TransformVmButton
callsEmsInfra.all.select(&:validate_import_vm).empty?
that boubles throught the backend to the Ovirt provider
app/models/manageiq/providers/redhat/infra_manager/vm_import.rb
and that in turn makes a API call to figure out the versions of the API supported somewhere in
app/models/manageiq/providers/redhat/infra_manager/api_integration.rb
The API calls seem to be cached but that is of little help if the Appliance with the UI worker does not "see" the provider (which is a perfectly valid and supported usecase).
In my testing environment this surfaces by a 2m 11s delay when clicking on a VM in an explorer tree before the VM details (textual summary) is displayed (after a network timeout).
This is easy to confuse the user into thinking that everything is hanged, clicking the tree node again and again and getting all the UI workers/threads/processes blocked on network timeout trying to reach the RHEV/Ovirt provider resulting in a complete DOS of the UI.
ref: #383
ping @matobet
I don't know if this affect the Fine release (the UI code is in Fine, but the manageiq-provider-ovirt version might be different). In case it's in Fine, we need a BZ.
The text was updated successfully, but these errors were encountered: