"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. "
Not to cause offense BTW, but I find this kind of language to be the antithesis of everything I'm building with Ansible. It's exclusionary, and I don't understand a word of what you're talking about. It's going to be very hard for anyone to be able to reply to your thought process. See also: http://www.youtube.com/watch?v=RXJKdh1KZ0w On Sat, Nov 23, 2013 at 10:50 AM, Michael DeHaan <[email protected]>wrote: > We've mentioned we're rolling out a roles repository called Galaxy in a > few weeks. It will have a CLI. > > Patience, grasshoppper! > > > On Fri, Nov 22, 2013 at 5:18 PM, <[email protected]> wrote: > >> 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. >> > > > > -- > Michael DeHaan <[email protected]> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- 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.
