# I think we can actually merge func-command with bin/ansible actually... **URL:** \ **Category:** Ansible Project\ **Created:** [February 29, 2012, 3:21am UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314 "2012-02-29T03:21:39Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 29, 2012, 3:21am UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/1 "2012-02-29T03:21:39Z")
Maybe we can get away with this. - merge ansible-command into ansible The DEFAULT module, if not specified, is command Any “free” arguments (non options) get fed into module\_args if module\_args is not supplied. That way, cool things like the output tree, one line output, which are totally useful to the other non-command modules, can be rolled up and made available to other modules. In other words, I want one line summaries for things like “ping”, or if someone wrote a trivial module for uptime, etc, etc. And that means…. DRUMROLLLLLLLLL…… that we can implement func-inventory equivalency in terms of the tree output already in the command script. Just to show this is more or less usable, assume: ansible [–one-line] [–tree] -p “\*” /bin/echo hi mom That’s just like the command wrapper. –Michael ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 29, 2012, 4:15am UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/2 "2012-02-29T04:15:14Z")
I went ahead and did this. The major upside is there’s going to be much less code to maintain in the long run. We can work out what features I inadvertently killed that are important – most of Seth’s work remains intact and the output is much improved over the JSON for all modules. I still have code to handle commands special – and I think they are the only ones that really SHOULD be special, because if you want formatted output, you’ll run a command. Most other modules are much more likely to be hit by ansible-playbook or the API. I should probably also work on letting the module\_args parameter be a hash for key-value stuff in the API and auto-convert it, so it’s more DWIM versus always taking a string, etc. Anyway, ansible-command is removed, but all good ideas remain 🙂 I think aliasing ansible-command to “-n command” should be mostly workable, I think we can prob still do better about module\_args and not needing -a. –Michael ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [February 29, 2012, 6:07am UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/3 "2012-02-29T06:07:48Z")
you've got to nuke -p '\*' though. That's not how people think. After no one in FI using func, at all, for well over a year, despite it working, I wrote func-command and 'woosh' all of a sudden it is being used all the time. the reason was a couple of things: 1. everyone groks --host 2. the default needs to always be 'all our hosts' 3. if the host specified by --host is not in the list of hosts, just assume the sysadmin is not an idiot and try a connection to that name/ip/etc. The reason is that if the name doesn't show up in our host list it is likely some random-ass alias that the admin uses. So I'm completely fine with merging in the basic command functionality into the ansible command that's a good idea but don't call the host glob 'pattern' just call it 'host'. If we want to disentangle hostlist and host - then come up with another name for hostlist - but --host is what folks definitely understand. Pattern only makes sense if you know you're matching against a hostlist. does that make sense? -sv ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 29, 2012, 1:11pm UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/4 "2012-02-29T13:11:50Z")
Ok, let’s review all the things we want to make possible and then we can come up with a syntax for resolving the combinations - I want to be able to have groups of systems - I want to be able to target hosts in a particular pattern from my inventory file - I want to be able to target specific group(s) in my inventory file - I want to be able to use an inventory file not in /etc/ansible because I installed ansible as non-root without IT admin’s ok. - I want to be able to be able to do hosts not in the inventory file Proposal: - “-p” becomes “-h” in /bin/ansible - specifying the inventory file becomes “-i” or similar in /bin/ansible - the default value for -h is “\*”, matching everything in the inventory file - the ansible hosts file can have group headers like [webservers] - if a pattern specified is a group name, it is used _directly_ instead of as a pattern match - otherwise a pattern is tried as we have currently implemented - if a pattern fails to match anything completely, it is tried as an explicit hostname I think this could be easily workable and intuitive. Sound good? –Michael ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [March 1, 2012, 7:42am UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/5 "2012-03-01T07:42:23Z")
> Ok, let's review all the things we want to make possible and then we > can come up with a syntax for resolving the combinations > > - I want to be able to have groups of systems Isn't groups of systems implicit within the hostlists? If you have a different group just specify a different hostlist? so if your global list is /etc/ansible/hostlist you can generate group lists whenever and just point to them with -H? > - I want to be able to target hosts in a particular pattern from my > inventory file > - I want to be able to target specific group(s) in my inventory file okay. So you want multiple groups at a time. - not just multiple hostlists. Gotcha. > - I want to be able to use an inventory file not in /etc/ansible > because I installed ansible as non-root without IT admin's ok. > - I want to be able to be able to do hosts not in the inventory file clear. > Proposal: > > - "-p" becomes "-h" in /bin/ansible    +1 > - specifying the inventory file becomes "-i" or similar > in /bin/ansible > - the default value for -h is "\*", matching everything in the > inventory file > - the ansible hosts file can have group headers like [webservers] why not just do a separate groups file so you don't have to start parsing the hostlists in a special way. > - if a pattern specified is a group name, it is used \*directly\* > instead of as a pattern match > - otherwise a pattern is tried as we have currently implemented > - if a pattern fails to match anything completely, it is tried as an > explicit hostname > > I think this could be easily workable and intuitive. Sound good? sure. One addition: If you're going to have patterns - might as well add negation patterns. so I can do things like: pattern=\*.fedoraproject.org;!app01.phx2.fedoraproject.org Which would just mean all matching \*.fedoraproject.org but not app01. (mainly b/c app01 is 'odd') 🙂 -sv ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [March 1, 2012, 1:15pm UTC](https://forum.ansible.com/t/i-think-we-can-actually-merge-func-command-with-bin-ansible-actually/11314/6 "2012-03-01T13:15:07Z")
> > Ok, let’s review all the things we want to make possible and then we > > can come up with a syntax for resolving the combinations > > > > - I want to be able to have groups of systems > > Isn’t groups of systems implicit within the hostlists? If you have a > different group just specify a different hostlist? It does that, yes, though I can also implement groups in about 5 lines of code, so I’m going ahead and allowing it [webservers] 192.168.1.1 [dbservers] 192.168.1.2 [dbserver.example.com](http://dbserver.example.com) etc FWIW, I think this is more or less what Adrian (I think) added when he did groups in Func. Eventually I want these to be manipulatable via another script like ansible-hosts or something, but that’s total extra stuff so it can come later. Think about “I have this pattern, what does it match” and wanting to look in advance, wanting to easily put a system in multiple groups, list the group it is in, remove a system, etc. Keeping it simple to start with. I suspect 95% of users will just have one inventory / host list file. > okay. So you want multiple groups at a time. - not just multiple > hostlists. Gotcha. yep yep! > > > > why not just do a separate groups file so you don’t have to start > parsing the hostlists in a special way. sounds like extra work and I like everything in one file. Plus parsing is crazy simple. > > - if a pattern specified is a group name, it is used _directly_ > > instead of as a pattern match > > > - otherwise a pattern is tried as we have currently implemented > > - if a pattern fails to match anything completely, it is tried as an > > explicit hostname > > > > I think this could be easily workable and intuitive. Sound good? > > sure. One addition: > > If you’re going to have patterns - might as well add negation patterns. > > so I can do things like: > > pattern=\*.[fedoraproject.org](http://fedoraproject.org); ![app01.phx2.fedoraproject.org](http://app01.phx2.fedoraproject.org) That would be easy to do. I’ll accept a pull request for that once I get the basics in. Probably hammering this out tonight so it can be done and we can stop moving options around. as we build up users they will eventually be confused if they shift too much, but I think it’s totally fair in the first week of the project 🙂