On Monday 25 of February 2013 23:40:24 Duncan Mac-Vicar P. wrote: > While it is easy to calculate the status of the repo-sync, -- as every > channel sync has _one_ taskomatic job which has a result --, the status > of the metadata generation is in _one_ Taskomatic job which creates > workers for every channel. However the status is lost one it runs. The > items in the worker table are basically the "scheduled" and "running". > > If we want to improve here, I see 2 alternatives: > > - Improve this table (workers) to keep the failed and successful workers > for a channel metadata generation run.
Hello Duncan, If you mean the taskomatic worker would update the channel status after a (un)successfull generation, then yes, it shall be possible. > > - Keep it like it is, but make some assumptions: > - If the metadata directory does not exists, it has not run yet (so > it is not completed, but unknown). Right. > - If the metadata dir is there, but there is a FAILED file (written > when the worker throws) then it is failed If a worker fails, we may update the status in the catch block. > -> Michael also suggested looking for .new files to detect "failed" > state. If there're .new files in the directory, the repodata generation shall be 'In Progress'. I mean they're not kept, if a repo worker fails. > - If the metadata dir is there but not the above, then it is completed. > > What do you think? Detection of the correct state is complex, the question is how many states you want to consider/show on the webui. The only part of code, that generates the repodata is the taskomatic reporegen worker. I'd suggest to set the state to 'in progress' after a generation starts, to set it to 'failed' if the worker throws an exception (we saw some out of memory exceptions in case of large channels) and to 'completed', when the worker succeeds. Initial state may be set according to the presence of the repomd.xml file in the appropriate directory to either unknown(/missing) or completed. I wouldn't consider a 'scheduled' state due to the need to periodically query the rhnRepoRegenQueue table. With this approach you have the problem, if the root deletes the repodata from the filesystem. Optionally ChannelRepodataDriver check also that, but I wouldn't implement it in the first phase. > > Duncan Regards, -- Tomas Lestach RHN Satellite Engineering _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
