DebOps scripts

This is right now a brainstorming page for new ideas an updates to the Python scripts used by DebOps. Your ideas and comments are welcome!

Change the user interface to be more git-like, with subcommands. This requires a better command parser to get the commands for the debops script separate from commands for ansible-playbook', and will require changes to how DebOps is used, but it might open up more options in the future.

Ideas:

# Run the Ansible playbooks
debops run playbook1 playbook2 --limit group --tags tag1

# Create new DebOps project directory
debops init path/to/project

# Update DebOps roles and playbooks
debops update

# Update DebOps playbook in custom location
debops update /usr/local/share/debops

# Display latest changelogs, something like git log
debops log

# Display changes in specific role
debops log debops.mariadb
debops log mariadb

Switch from using .debops.cfg configuration file in the project directory to .debops/ directory with .debops/config inside. This directory can be used for other things related to the project directory.

Each project directory could specify its own main Ansible playbook. tjat would allow for multiple sets of playbooks for different environments rather than one large site.yml playbook.

An idea to generate playbooks dynamically before passing them to ansible-playbook, to sidestep issues with public, static playbooks. This would allow to modify the playbooks easily by adding your own roles/tasks to them. There should be a simple templating system (probably Jinja) with variables that specify what roles and tasks should be included in a playbook. Dynamic playbooks should be scoped per project directory. Static playbooks should also be available and usable.

Main configuration file should support a list of git repositories that should be installed in the /usr/local/share/debops or ~/.local/share/debops directory. This would enable custom repositories similar to debops/debops-playbooks, ability to download git repositories from outside GitHub (for example a private GitLab instance, or DebOps GitLab instance if we decide to move), allow for easy separation of Ansible plugins and modules to a separate git repository, etc.

Using git repositories for distributions is very handy but takes a long time to update all roles. When roles are versioned, an alternative distribution method could be handy, perhaps based on tagged tarballs (GitHub supports this).

The configuration file should use similar style to ansible.cfg configuration, variable names with underscores instead of hyphens.

Right now DebOps is hardcoded to use ansible/inventory/hosts for its hosts file and it searches for a debops.cfg to use. Being able to override these would allow us to use a totally different hosts file and search paths for DebOps. If you could override the hosts file setting in debops.cfg, just allowing a custom debops.cfg to be specified would allow this.

The git-subrepo command allows you to create a master repository with sub-repositories. The nice thing about this is when checking out the master repository, you don't need to know anything about git-subrepo. This would allow us to do releases by updating the master repository, yet keep the roles in their own separate repositories still.