Why rerun?

Don't tools like chef and puppet for configuration management or mcollective, fabric and func for distributed execution already cover the bases? The answer to that question is "Yes". So why introduce a tool like rerun?

During my travels in large mature enterprise organizations I see a not-so-uncommon need to enhance traditional shell scripting approaches that facilitate handoffs between teams.

Rerun is aimed more at organizational issues and not technical ones. You might find rerun useful for groups that have scripting skills but are unable to adopt a more sophisticated (and probably superior) alternative.

Here are some virtues rerun aims to achieve:

• Stupid simple. The rerun implementation is one executable script.
• Establish common invocation and option passing. Put a standard calling syntax on your scripts.
• Modularity: Scripts are organized into rerun modules.
• For mature orgs that have political restrictions. Some teams can't foist ruby or python writing skills on other teams.
• Might be a path of least resistance for devs to hand over traditional scripts to the ops side of the house.
• Simple convention. Scripts (and optional metadata) are organized into simple directory layout.
• Includes a tool to help create modules. The included "stubbs" modules will help you maintain rerun conventions.
• No root user. Rerun does not assume you are running as root (and I would discourage it if sudo can be used).
• Nice operating environment. Rerun bash command completion makes it easy to list and use rerun commands.

Why the name?

Who doesn't find inspiration mining TV culture for a suitable campy yet short name for their open source project?

Next steps

Installation