As I was working on the performance enhancements for the SSM bulk channel subscription change (https://bugzilla.redhat.com/show_bug.cgi?id=469984) I started to wonder if our approach to the SSM in general could use a little work. Given the fact that there can potentially be a large number of servers selected, I think the whole setup lends itself towards an asynchronous model.
I see it going something like the following: - At least for the first pass, use the workflow of the existing SSM pages as they are today (ported to Java, and we can reevaluate each instance as needed). - After selecting to confirm whatever action is being done, instead of waiting for the action to finish before returning, drop the user to a generic "SSM Action History" (action may be a bad choice of words here, but I'm open) page. - This page contains a list of each thing the user did against systems in the SSM. The list can contain: -- Rough description of what the action was (e.g. "Change channel subscriptions" or "Delete servers"). Perhaps even editable by the user at the time of confirming the action. -- Current status of the action (e.g. "In Progress", "Completed", "Timed Out", "Cancelled") -- Timestamp of when started and/or completed and/or last updated. -- Progress complete. Even if this is just done in increments of, say, 5%, I'd like to be able to show that the action is at least doing something. Chunking the updates to this will prevent an update per server in the set and be able to provide feedback without adding too much extra load to the DB. -- Some sort of link to the individual event scheduled on each server, if applicable. We might even be able to have some logic that looks at the individual events so when viewing the details of one of these SSM actions, we can see which servers ran into errors. I think with a little extra effort this sort of thing can provide much more visibility into SSM operations than currently provided. This would also be pretty important given the volatility of the servers in the SSM; since they aren't named (in other words, reasonably static) groups, I think it'd be helpful to keep the association of which SSM actions go with which servers. We could even throw a quick status near the SSM "Manage" and "Clear" buttons to indicate how many actions are currently in progress, so as the user continues to navigate around they have a quick indicator of if an action completes. Outside of what we track for a request, the big question is how to thread off the work. One possibility is taskomatic, which I'm not entirely familiar with. I do see from the wiki that we have tasks scheduled for once a minute, which I think is an acceptable delay before one of these SSM actions begins to process. I think we have to be able to allow more than one of these SSM actions to take place concurrently, however there is a definite upper limit to how many we should allow at once. We'll also need a mechanism to time out these actions and potentially a way for a user-initiated cancel. I'm not sure if it's possible to exercise this sort of set up through taskomatic/quartz. Anyone familiar care to comment? Otherwise, outside of EJBs, I'm not sure of any other options (besides just spinning off my own threads, but I doubt we want to go that route). Thoughts? - J -- Jason Dobies ([email protected]) RHN Satellite & Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk, #spacewalk-devel _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
