Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best Practise Configuration (or: how to use 'playbooks-paths'?) #116

Open
ganto opened this issue May 25, 2015 · 3 comments
Open

Best Practise Configuration (or: how to use 'playbooks-paths'?) #116

ganto opened this issue May 25, 2015 · 3 comments

Comments

@ganto
Copy link
Contributor

ganto commented May 25, 2015

For a while I'm trying to find the best way how to easily extend DebOps with my custom roles. However, I'm failing to find a satisfying configuration.

So far my approach was to create a custom <project>/ansible/playbooks/site.yml where I include the upstream site.yml at the end. The dirty hack in this configuration is that the upstream site.yml has to be given with a concrete path. E.g.

  # This playbook contains the debops setup.
- include: /var/lib/debops/.local/share/debops/debops-playbooks/playbooks/site.yml

Is there a variable which can be used in the YAML to get the upstream playbooks path?

Problem: Using playbooks-paths
When looking through the documentation I found that there is a playbooks-paths variable which is documented as:

List of comma-separated paths where playbooks can be found. debops script will search these
paths looking for playbooks to execute.

So I tried to move my custom site.yml to a separate path which is listed in playbooks-paths (btw. the parsing only works when the definition is newline separated, not comma separated):

playbooks-paths: ~/my-playbooks
                 %(install-path)s/playbooks

The problem now is, that because the site.yml is first found in my custom location, the roles_paths is expanded to only include role directories relative to this playbook path. This makes it impossible to run upstream roles.

So I deleted the site.yml from my custom directory, which now fixes the role lookup. But no custom playbooks are run anymore, what defeats the purpose of the configuration.

Problem: Expanding roles_paths
Alternatively I tried to add the %(install-paths)s/roles path to the roles_paths variable in .debops.cfg which resulted in this error:

Traceback (most recent call last):
  File "/usr/local/bin/debops", line 174, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/usr/local/bin/debops", line 111, in main
    config = read_config(project_root)
  File "/usr/local/lib/python2.7/dist-packages/debops/config.py", line 113, in read_config
    for sect in cfgparser.sections())
  File "/usr/local/lib/python2.7/dist-packages/debops/config.py", line 113, in <genexpr>
    for sect in cfgparser.sections())
  File "/usr/lib/python2.7/ConfigParser.py", line 655, in items
    for option in options]
  File "/usr/lib/python2.7/ConfigParser.py", line 691, in _interpolate
    self._interpolate_some(option, L, rawval, section, vars, 1)
  File "/usr/lib/python2.7/ConfigParser.py", line 723, in _interpolate_some
    option, section, rest, var)
ConfigParser.InterpolationMissingOptionError: Bad value substitution:
        section: [ansible defaults]
        option : roles_path
        key    : install-path
        rawval : /roles

Obviously %(install-path) cannot be correctly expanded when used under [ansible defaults].

Questions:
I don't really understand how people are using these configuration statements.

  • Is anyone else having problems with this?
  • How are you managing multiple projects which are using common code (playbooks, roles) outside of DebOps?
  • Is someone using playbooks-paths?
  • Is anything wrong with always adding the upstream roles location to the roles_paths?
@drybjed
Copy link
Member

drybjed commented May 25, 2015

I don't combine "standard" DebOps playbooks and custom playbooks into one, in other words, I usually run just standard playbooks/roles and custom roles are executed separately as needed from project/playbooks/ or project/ansible/playbooks/.

I'm not sure how playbook include in Ansible works when playbooks and roles are in completely different paths, if it creates issues I'm open to changes in the scripts or configuration as needed.

So, how do you guys use custom roles/playbooks with DebOps? Any experiences that can be defined as best practices?

@carlalexander
Copy link

I'm also curious how to extend debops. I considered doing something like @ganto, but you mention separate playbooks for new roles in a few issues. I tried doing it that way.

I don't combine "standard" DebOps playbooks and custom playbooks into one, in other words, I usually run just standard playbooks/roles and custom roles are executed separately as needed from project/playbooks/ or project/ansible/playbooks/.

I feel there might be an issue with the default configuration to do this as well. Or maybe it's just missing documentation. Or I'm missing something.

EDIT: After more troubleshooting, I moved this to a separate issue.

@jstruebel
Copy link

I am trying to do something similar, but in my case to provide a set of common playbooks based on the debops roles. The issue I'm finding is that all of the roles and plugin paths are determined relative to the playbooks-path. For me this is causing trouble since I still want to use the roles and plugins with the common playbooks.

Specifically I want to create a common set of playbooks to manage sets of TurnkeyLinux appliances from their Ansible appliance. Ideally, the user would install debops, install the comon playbooks to a path like ~/.local/share/turnkey/tkl-playbooks, run debops-init, and set the playbooks-paths. Initially my thought was that the common tkl-playbooks would replace the debops playbooks, but maybe a user would want to use the debops ones alongside the common ones. In any case they would still need access to the plugins and roles from debops since I don't think it makes sense to try and duplicate those.

I think that allowing the playbooks-paths to contain multiple paths with the first having priority, no matter what paths may have a site.yml, would provide the most flexibility. It would allow the following priority for all items: project->site custom->debops. I think that this would be a best practice for re-useability at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants