A node-based web interface for the <a href="https://github.com/OptimalBits/bull">Bull Job Manager</a>
Update Note version 0.1.0 -> 1.0.0
In the latest update, Matador went from relying on Kraken to relying on just express/dust (which is why I incremented by a major version number). This occurred because Kraken has changed quite a bit since Matador was made, with quite a bit of the previous code becoming deprecated. I also re-worked some of the code to try to make it quicker and resolve some of the issues/feature requests.
We needed a job manager and we wanted to stick to one that only really relied on Node and Redis, so we looked and looked until we found Bull. Bull looked really nice, but we also wanted to be able to monitor the jobs without having to actually log into the AWS server to access the Redis database. Thus, Matador was born.
Why not just use Kue?
Kue has some <a href="https://github.com/LearnBoost/kue/issues/53">really old</a>, <a href="https://github.com/LearnBoost/kue/issues/130">outstanding bugs</a> that we encounted just while testing it. We tested Bull quite a bit, and couldn't reproduce these bugs. We thought it'd be easier to build an interface for Bull than to use Kue and deal with those bugs. (Notice that the first one, while closed, was never actually fixed...)
Easy! If you're using Bull already, then all you need to do is pull this repo and run it
If you're not using Bull, and you think you want to use Matador for some reason, then you should go check out Bull over <a href="https://github.com/OptimalBits/bull">here</a>. After that, if you decide you like it, come back and check out Matador!
What is it built on?
Matador requires Node (obviously) and is built on Experess. Other NPM packages utilized include, but are probably not limited to:
- Font Awesome
What is a stuck job?
A stuck job is a job that has no state. It's possible that jobs listed as stuck are just in between states, but if there's ever a job with no state for a long time, the overview page gives you a place where you can delete or revert such jobs back the pending queue. Because stuck jobs are any job without a state, and while jobs are processing they may become stateless, there is no way to mass-manage stuck jobs. This is because it would be really easy to accidentally modify jobs you didn't mean to if a job was being processed while you were mass managing "stuck jobs".
The MIT License (MIT)
Copyright (c) 2014 Shane King
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
@dionjwa It looks like there's a file under
/usr/src/matador-bull-ui/config/production.json that you can override which, by default, has:
Would be nicer if there was a way to provide this information through environmental variables.
How do you use this? For example, how do you specify the redis host?