Bug 854289 - RFE: notification mechanism for submission and slot changes/updates
RFE: notification mechanism for submission and slot changes/updates
Status: CLOSED WONTFIX
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: condor-aviary (Show other bugs)
Development
Unspecified Linux
high Severity high
: ---
: ---
Assigned To: grid-maint-list
MRG Quality Engineering
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-04 10:58 EDT by Pete MacKinnon
Modified: 2016-05-26 15:43 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-26 15:43:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pete MacKinnon 2012-09-04 10:58:26 EDT
In the absence of the QMF object updates available to Cumin for slot and submission updates, Aviary will attempt to provide an alternative mechanism for these notifications.

A client such as Cumin will register a callback endpoint to Aviary by which the appropriate Aviary endpoint will push one-way updates for slot (e.g., state, activity) and submission (e.g., running, idle totals) changes. This callback interface will be expressed externally to the client in WSDL by which they can provide a generic URI that Aviary will use to push a payload (XML to start) of updates to the receiver. The one-way operation will be InOnly and only synchronize to the HTTP/HTTPS transport, not the remote implementation. Thus, the receiver will have to consume the message and process it in a different thread to maintain system throughput.

The client will also be able to specify a batch size and frequency upon registration which will be used by Aviary to implement a per-client throttle policy. These may be governed by hard and soft limits specified within Condor/Aviary configuration. Graceful disconnects will be the repsonsibility of the registering client through a provided WSDL operation (e.g., "unregister"). However, garbage collection of dangling registrants will also be implemented based on a TBD policy.
Comment 2 Anne-Louise Tangring 2016-05-26 15:43:53 EDT
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.

Note You need to log in before you can comment on or make changes to this bug.