I think we can actually merge func-command with bin/ansible actually...

Archives Ansible Project
1

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

2

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 :slight_smile:

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

3

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

4

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

5

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') :slight_smile:

-sv

6

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

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;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 :slight_smile: