Using with_items with the package command results in a new transaction
for each item. This process can take a long time with long package
lists. Updated package tasks to pass a string of packages to the
package command resulting in a single transaction for optimal execution.
Attempt to give component owners autonomy and ensure that PRs
automatically receive assigned reviewers.
Just a first pass, open to changes in the future
Change the defaults for node bootstrapping to true, all nodes will
bootstrap unless opted out. Remove containerized node artifacts
Remove the openshift_master role - it is dead.
In Ansible 2.2, the include_role directive came into existence as
a Tech Preview. It is still a Tech Preview through Ansible 2.4
(and in current devel branch), but with a noteable change. The
default behavior switched from static: true to static: false
because that functionality moved to the newly introduced
import_role directive (in order to stay consistent with include*
being dynamic in nature and `import* being static in nature).
The dynamic include is considerably more memory intensive as it will
dynamically create a role import for every host in the inventory
list to be used. (Also worth noting, there is at the time of this
writing an object allocation inefficiency in the dynamic include
that can in certain situations amplify this effect considerably)
This change is meant to mitigate the pressure on memory for the
Ansible control host.
We need to evaluate where it makes sense to dynamically include roles
and revert back to dynamic inclusion if and where it makes sense to do
so.
We now use a CPU request to ensure logging infrastructure pods are
not capped by default for CPU usage. It is still important to ensure
we have a minimum amount of CPU.
We keep the use of the variables *_cpu_limit so that the existing
behavior is maintained.
Note that we don't want to cap an infra pod's CPU usage by default,
since we want to be able to use the necessary resources to complete
it's tasks.
Bug 1501960 (https://bugzilla.redhat.com/show_bug.cgi?id=1501960)
In a project where contributors are free to use whatever editor they
want and we have linting tools that verify the proper formatting of
Python files, it should not be required to have a vim-specific line in
Python files.
The contents are outdated and irrelevant since the "best practice" is
automatically enforced.
Documenting the PR flow is out of the Best Practices guide.
