Bug 719329
Summary: | (enhancement) add an operation results page that polls the Server for operation completion and displays the results once the operation has completed | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Ian Springer <ian.springer> |
Component: | Core UI | Assignee: | Nobody <nobody> |
Status: | NEW --- | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0.1 | CC: | hrupp, takezoe |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | --- | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ian Springer
2011-07-06 14:00:35 UTC
Thanks Ian for raising issue from my request. It might have a problem with long-running operation such as start or shutdown servers. So I think it would be nice if it's selectable for each operation. Now RHQ provides 4 options for operation scheduling: - Now - Now & Repeat - Later - Later & Repeat My idea is adding new option 'Synchronized'. We can specify whether an operation supports 'Synchronized' option or not at operation definition in the rhq-plugin.xml as following: -------- <operation name="helloWorld" supportSynchExec="true"> ... </operation> -------- If supportSynchExec is true, 'Synchronized' is selected in default at the operation scheduling settings, otherwise it can't be chosen. I assume you mean "Synchronous" not "Synchronized". I'm not sure that would be necessary. I was thinking that the user would always be taken to the operation results page after scheduling an operation to run Now. For long-running operations, they could always navigate away from the page at which point the GUI would stop polling the Server unless they returned to the page. The tricky part is that the results are ultimately part of an operation history item, and there is currently no relationship in the db between an operation schedule and the operation histories corresponding to invocations of that schedule. However, an operation history item does include the Quartz job name, by which the schedule could be queried. A related improvement in the operations GUI would be to add a table on the details page for an existing operation schedule that lists all operation history items, if any, corresponding to that schedule. Without a db relationship between schedules and histories, this would involve querying for all histories with the same quartz job id as the schedule. If we did this, then we could just always redirect users to this page after they create a schedule, even if they specified Now & Repeat, Later, or Later & Repeat. |