platforms: automatically group hosts and aply sane defaults per platform (windows, linux distro, network OS, etc)

[bcoca]

Proposal: platforms

Author: Your Name <@yourGHid> IRC: handle (if different)

Date: 2017/xx/xx

• Status: New
• Proposal type: core
• Targeted Release:
• Estimated time to implement: X days

Motivation

Allow quicker setup to users by defining 'prexisting' platforms/groups that will configure a set of connection variables 'known to work' in conjunction.

Solution proposal

A default set of groups from an 'internal inventory' that are available for use any inventory

# lib/ansible/config/platform.yml
all:
  children:
    ansible__windows_platfrom:
       vars:
          ansible_connection: winrm
          ansible_shell_type: powershell
          ansible_become_method: runas
          ansible_remote_tmp: C:\temp
          ansible_gather_facts_modules: ['win_setup']  # doesn't exist, but PR that allows this in queue
          ansible_module_exts: ['.ps1', '.exe', '.bat', '.cmd']  #  does not exist, but easy to add

    ansible_sunos_platfrom:
       vars:
          ansible_remote_tmp: $HOME/.ansible/tmp  # adding in 2.5

    ansible_aix_platfrom:
       vars:
           ansible_world_readable_tmp: True  #  adding in 2.5

    ansible_ios_platform:
        vars:
            ansible_connection: local
            ansible_persistent=True
            ansible_gather_facts_modules:
                - netconf_facts
                - ios_facts

So users can just assign hosts to these groups in any other inventory and the vars/settings will be applied to those hosts.

Anything else?

This can work well with a persistent fact cache and the contstructed inventory plugin and/or some 'pre detection' to classify the hosts to make new setups/adding newly provisioned hosts in a very quick way to inventory and start working with Ansible

[alikins]

use case?

Are there existing issues that would be resolved by this?

[alikins]

'ansible_platform' would be a fact?

Would there be a 'platform' keyword for plays/tasks ?

Are the platform definitions built from config? Could playbooks or roles define them? Could playbooks or roles extend or override them?

How would someone share a platform definition?

Can the platform definitions include variables and templating?

Whats the var precedence?

[alikins]

What all can a platform definition set? Only connection variables?

[bcoca]

use case? Are there existing issues that would be resolved by this?

No open issues, as 'motivation' states this just makes it easier for users to get started with Ansible

'ansible_platform' would be a fact?

No, we might need to change the name to disambiguate ...but it can be used with facts/inventory data to autoassign

Would there be a 'platform' keyword for plays/tasks ?

No, it fits more with inventory than with play objects.

Are the platform definitions built from config? Could playbooks or roles define them? Could playbooks or roles extend or override them?

yes ... possibly, not sure why they would need to expand them, they are mostly intended for quick setup to be able to have hosts targeted with the correct connection/plugins/etc

How would someone share a platform definition?

depends on implementation .. but currently we could already do this by defining them as a group with associated variables.

Can the platform definitions include variables and templating?

I think the above already answers that

Whats the var precedence?

depends on implementation, but mostly they should be pre/post inventory vars

What all can a platform definition set? Only connection variables?

depends on implementation, it is geared mostly to connection variables ... not sure what else would make sense under these, but should be easy enough to expand.

[nitzmahone]

I have some concerns with implementing this simply as built-in groups with no other changes:

• It's difficult to reason about the state of connection vars introduced by other group memberships.
  • Could be mitigated by making platform groups the lowest in precedence, so that any "real" group the host is a member of can have normal group precedence behavior WRT any connection vars they might set.
• Host->group membership feels "wonkier" than just setting a hostvar like ansible_platform=windows, and also allows a host to "belong" to multiple platforms (which is almost certainly not correct), rather than being a "property" of the host like a var would be.
  • No reason we can't actually do the var assignment as a group under the covers, but maybe by generating the group name and controlling assignment later in the inventory construction. But at that point, given some of the other things above, would it just make sense to have a mapping of "final platform var value just sets all the other var values for that platform"?
  • The bogus multi-membership thing could be mitigated by enforcing that a host is always a member of exactly one platform group- either the default or an explicit/group assignment. If a host ends up in more than one platform group, it's a failure.
• Exposing "well-known" group names for platform potentially calcifies this implementation (eg, people will have to reference the groups in their inventories, and could potentially even use them as play targets)
  • Not sure if this is really an issue, but if we decide we need more than "just a group" down the line, this could be problematic.
• Plugins can't rely on group membership to do conditional behavior based on platform (eg, Powershell shell plugin on Linux must behave differently than Powershell on Windows, though largely the same)
  • Could be mitigated by adding a "platform" fact (could be problematic for non-Windows though- how granular do you get?), or by subclassing the Powershell shell plugin for Linux/Windows and doing the shared stuff on the base, and having the default windows platform select the windows+powershell subclass.

I think controlling all this stuff via vars makes more sense than using a simple group membership- the number of exceptions we need to make to current group behavior for robustness makes it feel like maybe groups aren't exactly the right thing for this.

[nitzmahone]

It could probably be argued that platforms should be composable like normal groups (eg, platform: windows + platform: server_2008r2), but I think we're getting into a major new precedence headache there.

[bcoca]

• For precedence issues we can set ansbile_group_priority on all to make sure they are the lowest, or even make them 'top' groups like 'all' itself and outside normal heir, if someone has a reason to override these vars at a group level they should be able to.
• As for being 'targetable', yes, this was a feature in my view.
• composing the platform groups .. I had not thought of this, could be a problem and restriction seems clunky solution.
• as for your example, I would have made server_2008r2 a 'child' of the windows one so it inherits vars but can override what it needs.
• not sure what the powershell issue is but seems like a connection var (which shell plugins will soon support) will solve it

[nitzmahone]

Yeah, sounds like there are decent workarounds to everything except the "can be a member of multiple platforms" issue. I'm not sure that issue is worth going a harder route or not. I haven't floorplanned a solution for "platform-as-a-var" yet, but I suspect it will be significantly gnarlier than this. If we can agree on the "one platform group per host" restriction, I think I'd be willing to call it "good enough". I also think this would work well enough for what networking needs, but I'd want to kick that around with @Qalthos and maybe @privateip a bit before making that call.

[jhawkesworth]

@bcoca I understand this is a readmap item for ansible 2.7 so I hope this comment is still timely.

This may be scope creep but I just noticed yesterday that the default module for ad-hoc ansible commands does not appear to be sensitive to the connection in use, meaning you can't use command lines like

ansible windows_host -a 'dir'

(Just to be clear, running ansible windows_host -m raw -a 'dir' does what you would expect though).

So would it possible as part of this to specify default module - or would this be a separate change to make default module a property of the connection plugin?

[bcoca]

@jhawkesworth any of the general configuration items is available, so it does seem to make a lot of sense to change to win_command when platform == windows cc @nitzmahone