Hi,

I'm hoping to give my role-lines default path values, on a per role basis.  
I'm trying to create a *imperative*-based repository for roles, and I think 
the ability to build a long path to every role in a simple way is 
absolutely key.  

That bit about imperative means: I hope to decompose states back into 
package-manager like quasi-commands, before optionally reassembling 
imperative-named roles into a declarative again, perhaps on a node-wide 
role level.  This probably sounds like gibberish.  What I want is a package 
manager-like experience when applying Ansible roles from a community-vetted 
repository that is multi-distro from the ground up, because declarative is 
great, but so is imperative, when you know you want finer telemetry.  The 
"Origin" option deomstrated below gives room for something like: this 
software comes from sourcecode on github, not EPEL.  Configuration by 
exception.

I would have approached this from a tags perspective, but I think we 
established that all tags in a play will run by default, if calling from a 
playbook, without a programmatic exception.

*Anyway, here's the project I created on GitHub to resolve the lack of an 
Ansible Roles Repository; it's called Plethorole 
<https://github.com/KnoesOS/plethorole>.  *

You may want to look over the readme to get a better idea where I'm going 
with all this.  

side note: All methods (imperatives and otherwise) are to be kept 
idempotent by policy unless absolutely necessary.

*Now, I'd like to get away from:*

----
# file: group_web

- hosts: group_web
  sudo: True
  roles:
    - plethorole/v1/init

# layering Plethoroles
- hosts: group_web:&dist_Ubuntu:&distvers_12.04:&distarch_86_64
  sudo: True
  roles:
    - 
plethorole/v1/dyn_all/dist_all/v_all/arch_all/policy_ipv6/ori_def/v_def/arch_def/twst_def/disable
    - 
plethorole/v1/dyn_debuntu/dist_all/v_all/arch_all/software_jailhouse/ori_github/v_def/arch_def/twst_def/install
    - 
plethorole/v1/dyn_debuntu/dist_all/v_all/arch_all/software_mdadm/ori_def/v_def/arch_def/twst_def/install
    - 
plethorole/v1/dyn_debuntu/dist_ubuntu/v_12.04/arch_x64/meta_base/ori_def/v_def/arch_def/twst_def/install
    - 
plethorole/v1/dyn_debuntu/dist_ubuntu/v_12.04/arch_x64/node_web/ori_def/v_def/arch_def/twst_vagrant/provision



*To calling Plethorole with something like this:*

----
# file: group_web

- hosts: group_web
  sudo: True
  roles:
    - plethorole/v1/init

# layering Plethoroles
- hosts: group_web:&dist_Ubuntu:&distvers_12.04:&distarch_86_64
  sudo: True
  plethoroles:

    - method=disable type=policy name=ipv6 

    - method=install type=software name=jailhouse
        dynasty=debuntu
        origin=github

    - method=install type=software name=mdadm  
        dynasty=debuntu

    - method=install type=meta name=base
        distribution=ubuntu
        distribution_version=12.04
        distribution_architecture=x64

    - method=provision type=node name=web
        distribution=ubuntu
        distribution_version=12.04
        distribution_architecture=x64

        



*Here's what I have for the beginning of the module.  I want to use the 
key=value syntax to build the path to the plethorole resource, using 
default values to simplify matters.  The overall effect would be 
configuration by exception.  That is, let's write one role for the broadest 
scope possible, forking existing roles to a more specific scope only when 
necessary, all while avoiding uber-long yaml files.All of this is 
definitely a work in progress:*

#!/usr/bin/python
# -*- coding: utf-8

# (c) 2013, Joshua Mark Dotson

DOCUMENTATION = '''
---
module: plethorole
author: Joshua Mark Dotson
version_added: "0.0.0"
short_description: Utilize a Plethorole
description:
  - Utilize Plethorole, a diverse stockpile of reusable Ansible roles, by 
specifying a target resource.
options:
  name:
    required: true
    description:
      - Name of resource
  type:
    required: true
    description:
      - Type of resource
  origin:
    required: false
    default: "def"
    description:
      - Origin of resource
  version:
    required: false
    default: "def"
    description:
      - Vesion of resource 
  architecture:
    required: false
    default: "def"
    description:
      - Architecture of resource 
  twist:
    required: false
    default: "def"
    description:
      - Twist of resource 
  method:
    required: true
    description:
      - Method of resource 
  dynasty:
    required: false
    default: "all"
    description:
      - Dynasty where the target Plethorole is located.
  distribution:
    required: false
    default: "all"
    description:
      - Distribution where the target Plethorole is located.
  distribution_version:
    required: false
    default: "all"
    description:
      - Distribution version where the target Plethorole is located.
  distribution_architecture:
    required: false
    default: "all"
    description:
      - Distribution architecture where the target Plethorole is located.
'''

EXAMPLES = '''
# Install OpenSSH client on Ubuntu.
- plethorole: method=install type=software name=openssh
                dynasty=debuntu
                distribution=ubuntu
                twist=client

# Provision as a "configure" node with an AWX on EC2 twist.
- plethorole: method=provision type=node name=configure
                dynasty=rhelish
                distribution_architecture=x86
                origin=ansibleworks
                twist=awx-ec2

# Install Jailhouse using GitHub.com-based source code on x86_64.
- plethorole: method=install type=software name=jailhouse 
                origin=github 
                architecture=x64

# Apply a community-vetted policy for disabling IPv6 on any distro.
- plethorole: method=disable type=policy name=ipv6

# Uninstall screen on any Debuntu-dynasty system.
- plethorole: method=uninstall type=software name=screen 
                dynasty=debuntu
'''




Please let me know where to start with such a module.  I realize Plethorole 
is somewhat contrary to the batteries included method, but I've found this 
to be a very interesting and powerful experiment.  I think grouping 
declarative statements into imperative statements a good way to go, given 
the deterministic ordering of most(?) Ansible playbooks.  I enjoy the 
batteries included approach; I believe Plethorole could compliment it very 
well.  

Thanks,
Joshua
-- 
Joshua Dotson
Founder, Wrale

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to