seomoz / qless

Queue / Pipeline Management
MIT License
294 stars 76 forks source link

`qless-config` binary #246

Closed dlecocq closed 8 years ago

dlecocq commented 8 years ago

When setting up a new qless instance, a common part of that is to set some configuration for the application name, heartbeat intervals, maximum concurrency, etc. To this end, we've written little snippets here and there depending on what fits with the project. From shovel tasks to Java-based command-line utilities (sadly, it's true).

Rather than write this utility in multiple languages, it makes sense to have it adjacent to the qless-web binary. Since most installations at least include the UI, that would mean that each installation would also then have access to this helper.

It provides two subcommands:1) dump, which prints out the current configuration as JSON and 2) load which accepts a path to a JSON file and sets the configuration accordingly. The load subcommand also accepts --clear which unsets any configuration present on the server that is absent from the provided config.

dlecocq commented 8 years ago

@neilmb and @phs might be interested

dlecocq commented 8 years ago

@neilmb @Pyrinoc @b4hand -- thoughts?

neilmb commented 8 years ago

This change LGTM, but I think we need more thinking about versioning and related packages.

I don't think that "x.y.z supports x.y" captures enough information (does it support (x-1).y too?). I might prefer to see the version numbers for bindings evolve separately, but find a place to keep some clear metadata on version support. (README files?)

dlecocq commented 8 years ago

One of the problems is that previous breaking changes in qless-core forward-ported old data. But that meant that if you were using an old client on your workers, but then touched it with a new client, you could conceivably break your cluster. So I'd like it to be clear that you can / can't use version X of the ruby client with version Y of the python client.

Another way to think of it is that each of the bindings is merely a thin wrapper around the core functionality. Additional utilities around that core functionality will grow and evolve (as it does here), but I think that fits reasonably as a single version number slot in the bindings.