List worker queue in worker_info
JamesDooley opened this issue · comments
Currently worker_info provides the host, running jobs, start and notify times and process pid.
It would be very useful to also provide what queue or queues are being listened to for that worker.
As it is now if you have two workers running on the same box there is no way to tell which is which.
Alternatively, if the queues are too hard to get listed (more advanced setups), being able to name the worker would likely provide a viable alternative.
In my use case I have a management interface that does work well for displaying scheduled, running and past jobs. But the worker information is somewhat lacking, since I run multiple workers on a single box.
Really too bad you've not brought this up before Minion 6.0 got released. We've just talked about this in #42 and on IRC, and consensus was that the feature is just not worth the cost with the use cases presented so far. The big problem now is that no matter what we decide moving forward, this feature would require breaking changes in the backend API, so we'll have to wait until Minion 7.0.
Allright, since this topic keeps coming up, i'll leave this one open for further discussion.
Let me back up and try to give a little bit more information on one of my use cases, and why this information is useful. I do have several systems running Minion, but this one is currently the more complex one.
I am working on a management interface for our ELK stack (log storage), and one of the features is to allow off cluster archiving of old data. If a customer has long term archiving we create a job in the 'backups' queue, which multiple archive servers could be listening on. When an archive server picks up a job it schedules a chain of jobs in its local queue (named by it's hostname) to actually archive the index. The big advantage here is that if a step fails I can retry that step without having to start over.
To avoid a single archive server from grabbing all of the archive requests, we decrement the backups worker max value (using TTOU). Since archiving large indexes could take up to an hour this allows other workers to handle smaller indexes. Once the final job in the chain is done in the named queue, we send the TTIN signal to the parent process (if it is the same pid that spawned the job chain) to allow it to accept more jobs. I see that TTOU / TTIN was just removed, I will work around that with commands or figure out a different way of doing that.
This process allows me to add and remove archive servers without having to configure anything, or have any sort of complex job management system on the interface side. Just add a job to the queue and the available workers will handle the rest.
Although this information is not required for the system to work, it does help identify potential problems and give an overview of how the cluster is performing. I will probably work around this and have the workers update a database entry to provide this information in the mean time.
This issue has been open for a very long time, and i still would like to see more worker information be made available through the API, but it doesn't look like we'll see a good proposal anytime soon.
Here's a first attempt at making more information about workers available. d81cb2a