> But of all the solutions here, I think it would be easier for us to just > reuse rhnServerAction and that infrastructure.. Config* stuff is built > in ... We could probably reuse the Event History UI to do the > failed/pending actions/ rescheduling, all that is built in. Its almost > like 1 query might to be changed for backend to ignore ssm-scheduled > task form rhnServerAction.. (I am sure I am trivializing by saying 1 > query but it shouldn;t be too difficult to work around that,. )
First off, thanks for all the feedback. I'm taking chunks from various e-mails and consolidating my replies. One thing I like about utilizing rhnServerAction is that if I remember correctly (admittedly my head's a bit cloudy right now) that is the table used to track things done to clients. If we get the mapping right between "SSM bulk operation" and rhnServerAction, we can use it for server-side things (delete server, change channel subs) as well as server-client things (package install). > The other nice thing about using the MessageQueue is that is running > *within* tomcat so if we wanted to show status in the GUI we can talk > straight to the queue in memory without having to go out over xmlrpc or > to a DB table in a polling mechanism to track progress. I'm not sure I follow what this gets us, but that may be due to assumptions I'm making in my head that I haven't properly communicated. I was imagining a single paginated page that shows all things done through the SSM, meaning we'd see both complete and in progress side by side: Change Channel Subs -- In Progress -- admin -- 1/28 4:17am Delete Servers -- Completed -- admin -- 1/27 11:04pm Delete Servers -- Timed Out -- admin -- 1/27 9:41pm Where clicking on an individual item shows more details about it. In both this idea and my above comment on the rhnServerAction, I'm thinking in terms of solving as many cases as possible with the same code. > Right now taskomatic doesn't allow on demand scheduling. It reads > the tasks defined in the config only. But it wouldn't be hard to add > say a XMLRPC server to Taskomatic (like we did with search server) > to send jobs to Taskomatic or adding the entries to a task table. I was thinking something like this as well. Quartz seems to be able to support all of what we need, it's just a matter of throwing some hooks to it into taskomatic and exposing them. This isn't me saying it's a better approach than the Message Queue; I don't know enough about it (read: didn't really know it existed until this thread) yet to comment on that. Would the MessageQueue support: - Setting a timeout on the operation so it's not spinning around forever. - Canceling a job in progress. - Limiting the number of current jobs (potentially by user and a global number of concurrent SSM jobs). I'm not sure Quartz supports that either, just something I'm trying to keep in mind. My understanding of SSM usage is that I don't think we should expect a dozen concurrent SSM jobs, but still something I'd like to code defensively around. So given the last case, if a new SSM request comes in and we check and see X many in progress ones, with taskomatic we could reschedule it to occur later. I'm guessing in the MessageQueue we could just sleep in the thread that's spawned, but I'm just kinda thinking out loud here. > I would vote against the MessageQueue because if you restart tomcat > you've lost all of your scheduling. Whereas if you were using > taskomatic, you still would have all the queued actions left in the DB. I don't expect these things to sit in the queue long. I'm looking to make the UI async, however it is not where we'd have the "schedule this for some time in the future" logic. So after the user confirms the action, I'm expecting it to start in pretty short time. Given that, I'm not so worried about losing queued items as I am interrupting an existing, long running batch of operations, which we really wouldn't be able to reliably restart on our own anyway. > We'd have to upgrade to a full blown appserver for EJBs wouldn't we? > So for now I'd say no to that. Totally agree, just throwing it out there. :) -- 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
