define rules for roles

[evgeni]

SUMMARY

as per discussion in https://github.com/theforeman/foreman-ansible-modules/issues/535, we need a set of rules (besides naming) how roles should behave to be included in this collection.

copying from the original issue, we thought about:

• roles should be topic specific / atomic / small / however you want to name it (= do one job and do it well)
• roles need to be generic for their topic (= no special cases for "that one weird repository")
• related roles should be driven by similar input, to ease combining them

ISSUE TYPE

• Feature Idea

[evgeni]

cc @nesanton for the input from your customer

[evgeni]

input from @nesanton:

• make roles "atomic" as in "only one family of modules", a foreman-related role should not use katello modules, and vice versa. any further glueing should be done via variables.
• roles need either have sane defaults that just work or a sane way to bail out and tell the user that there are missing prerequisites.

@evgeni:

• avoid Satellite naming in variables/tasks/role names etc
• copy https://github.com/RedHatSatellite/satellite-ansible-roles/blob/master/README.md

[evgeni]

During triage, @sthirugn asked for an example of "satellite specific" workflow that we'd not want 1:1 here. My example was "content acquisition and management". The below bleeds into #644, but I'm gona write it down here and y'all can read it ;)

Satellite users usually get their content from Red Hat, so they need to get a manifest from the portal, upload that manifest to Katello/Satellite, enable Red Hat repositories, sync them, create content views. Katello users (while they can do the same), will often use CentOS, Debian, etc, where the first steps are different: create a product and repository, point these at the upstream mirror servers. Then you can go and sync/create CVs.

So ideally, our roles are so "atomic" (I hate that word) that they can be used in either scenario. Which in return means, that if someone has a role for a full Satellite workflow (from manifest to CV), I'd love to see them splitting that role in at least two roles: one for "acquire content" (manifest to enable repo) and one for "manage content" (sync, publish). Then, if someone wants the same for CentOS/Debian, they need a new acquire_content role, but can re-use the manage content one.

[bagasse]

As I will start to work to moving our internal 'bare' configuration playbooks to roles/collection, maybe if our internal workflows are applicable here I will contribute them here instead of keeping it internal:

Foreman:

• As a user, I want to configure taxonomies (Orgs, Locs)
• As a user, I want to configure common foreman parameters (foreman settings, global parameters, auth sources, users, groups, external usergroups, roles...)
• As a user, I want to configure network related stuff (domains, subnets)
• As a user, I want to configure compute resources related stuff (compute resources, compute profiles, compute attributes)
• As a user, I want to configure provisioning (I didn't goes down in detail for this one, bit at least ptables, provisioning templates, arch, oses, installation media...)
• As a user, I want to configure puppet related configuration management related stuff (envs, hostgroups?, config_groups, smart_class_parameters)

Katello:

• As a user, I want to configure Content/Products to be synchronized on my instance (sync plans, content_credentials, products, repos)
• As a user, I want to (force) sync content
• As a user, I want to configure "distribution" part of my content (lifecycle envs, content views, content view filters)
• As a user, I want to configure content access from my hosts (activation keys, host collections?)
• As a user, I want to publish content

What about roles testing ? Should we make test playbook+vars files and record them like we do for modules ?

[ehelms]

I think https://github.com/theforeman/foreman-ansible-modules/issues/646#issuecomment-608480355 would be good to put against https://github.com/theforeman/foreman-ansible-modules/issues/644

As for this issue, now that we have some roles, I feel like we could add any of these "guidelines" to the README and close this out.

[willtome]

#1117 and #1118

[willtome]

This may be a helpful document to pull from https://github.com/oasis-roles/meta_standards/blob/master/README.md