https://github.com/linux-system-roles/selinux/pull/16

From my POV, a role should define a state, not changes. It means that if I specify some configuration using role variables, I expect that the system will be configured according to the variables and all other relevant changes will be reverted. That's why we drop all modifications first.

If I wanted to add only some context mapping, or change a boolean, I would add particular modules to my playbook.

(In reply to Petr Lautrbach from comment #3)
> From my POV, a role should define a state, not changes. It means that if I
> specify some configuration using role variables, I expect that the system
> will be configured according to the variables and all other relevant changes
> will be reverted. That's why we drop all modifications first.
> 
> If I wanted to add only some context mapping, or change a boolean, I would
> add particular modules to my playbook.

We have a problem with nomenclature.  The way Ansible uses the word "role", the actual implementation, and how it is used in the real world do not always fit the  the definition of "role" that you might be thinking of.

That said, in these context, we are not thinking of "role" as a 100% fully defined state.

Our customers often take a layered approach.  They may not know the final configuration at deployment time.  So they need to build it up in layers.  In a proper config management environment like Ansible Tower, all of these configs would be stored in Playbooks.  Either consolidated or stored as a collection that could reproduce the desired state.

When we first approached the Ansible team, our goal based on customer feedback was to provide a "stable and consistent configuration interface to RHEL that was compatible across multiple versions."  I fully expected them to tell us to build modules that could adjust for a given implementation provider and features based on the OS version.  But instead they guided us that Roles were the best mechanism to provide the level of abstraction and compatibility across releases.


If we take the approach in comment #3, then we immediately lose any ability to build up layers and reduce ability for users to benefit.  For example, in the docs https://docs.ansible.com/ansible/2.5/user_guide/playbooks_reuse_roles.html, it demonstrates an example of multiple roles layered

- hosts: webservers
  roles:
     - common
     - webservers

With this common usage of roles, it removes the ability for this selinux system role to be usable within the common or webservers roles.  So what benefit have we provided?

I am inclined to accept comment #2 as the complete state is defined by the higher level playbook.  Our goal for this "role" is the configuration interface to make it easier for users configure selinux across releases.

I will add that if we strongly feel there is not a need to provide any abstraction and there is no other benefit that this role provides, we could consider supporting and enhancing the current set of selinux modules

https://docs.ansible.com/ansible/latest/search.html?q=selinux&check_keywords=yes&area=default


However, I was under the impression that there was value to providing a single interface to selinux via this role.

Thanks for the explanation. It makes sense for me now.

PR merged.

test: tests/tests_boolean.yml tests/tests_port.yml tests/tests_login.yml tests/tests_fcontext.yml, and also tests/tests_all_purge.yml after https://github.com/linux-system-roles/selinux/pull/29 is merged.