Man, how I wish Kala and Dcron would just work together.

https://github.com/ajvb/kala

https://github.com/victorcoder/dcron

Fusing both would be AWESOME (I'd even like to help).

What Dcron gets right:

• Distributed by design
• Raft for the reliable parts, gossip for lightweight sync, a match made in heaven
• Linux mentality
• Dashboard included
• Good docs, nice website, looks serious

What Kala gets right:

• Built much more directly after Chronos, which has an amazing and battle tested API
• Using ISO durations instead of NIHing their own format
• Dependent jobs

Finish out all of the TODO's.

Examples:

1. Parent <- Child <- 2x Child
2. 2 Parent's with 1 Child attached to both.
3. Proper error handling
4. Document how it does and does not work.

From: #36 (comment)

Similar to #18, but specifically for node.js

Use abtime to be much more specific in my testing of the job scheduling.

Right before public release

I just discovered this: http://askubuntu.com/questions/339298/conveniently-schedule-a-command-to-run-later

Stats for each run:

• ExecutionTime
• Succuess
• RanAt
• NumberOfRetries

strings.Split(echo "hello world", " ") will get parsed as []string{"echo", "\"hello ", "world\""}, which may work in this particular case, but is not correct.

Solutions:

Use https://github.com/kballard/go-shellquote

or the workaround recommended by https://groups.google.com/d/msg/golang-nuts/qYVlLVR5504/o-Td7DU6qsIJ --

exec.Command("/bin/sh", echo "hello world")

Flags:

• Verbose Logging
• Default Owner
• Don't Persist Mode

Add language specific directories, and remove the left over crap.

It would be nice to be able to specify an alternate path for the jobdb rather the . . Thanks btw, this project looks great

From: #36 (diff)

Hi,
I think in client/client.go/New() the check for the optional slash "/" means to check for trailing "/", not for leading "/", and if so, it should use strings.HasSuffix(), not strings.HasPrefix().
Btw.: Nice work here.
Regards, Frank

From: #36 (comment)

1. Running a Python script
2. Running a Ruby script
3. Running a Node.js script

Right now we have a Redis implementation for a JobDB. Would be awesome to have Redis work as the JobCache and/or JobDB.

Logging is currently done via 222Labs common/go repo. This dependancy needs to be removed, unless we open source that repo before this one.

Add a pluggable backend for postgres.

Is it really necessary to include each route twice like that? Is this so people can append a / or not and still get what they want?

    r.HandleFunc(ApiJobPath+"{id}", HandleJobRequest(cache, db)).Methods("DELETE", "GET")
    r.HandleFunc(ApiJobPath+"{id}/", HandleJobRequest(cache, db)).Methods("DELETE", "GET")
    ...
    r.HandleFunc(ApiJobPath+"stats/{id}", HandleListJobStatsRequest(cache)).Methods("GET")
    r.HandleFunc(ApiJobPath+"stats/{id}/", HandleListJobStatsRequest(cache)).Methods("GET")

Currently, the go client library utilizes Sling to do the HTTP communication. This is not required, and we should simply use the standard library.

https://github.com/ajvb/kala/blob/master/api/api_test.go doesn't show up in the coveralls test results, but https://coveralls.io/builds/3291410/source?filename=api%2Ftest_utils.go does. What gives? Should coveralls filter out the test cases themselves? Is it as simple as the test_*.go vs. *_test.go?

RunAsUser can only be used when running kala as a priviledged user.

Related to #44

And add to install instructions.

Should:

1. Display a list of active and disabled jobs
2. Allow for the removal or disabling of a job
3. Allow for the manual starting of a job
4. Click to copy the Job's ID
5. Display Job Stats for each listed Job
   Maybe's:
6. Modal for BoltDB Stats?

• Total # of Jobs

  • of Active and # of Disabled

• Total # of Runs

  • of Successes and # of Errors

• Next Job Run time (When is the next scheduled job going to run at?)
• Last Job Run time

https://coveralls.io/