| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Since py3 returns `dict_items` for dict.keys() call instead of a list,
it should be converted into a list for compatibility
Signed-off-by: Vadim Rutkovsky <vrutkovs@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
files, use diffs to keep custom changes, white list certain settings when creating diffs
|
| |
|
|
|
|
|
| |
Move openshift_deployment_type check into sanity_check
action plugin. Remove compatibility for deployment_type.
deployment_type has been deprecated for some time now.
|
| | |
|
| | |
|
| |
|
|
| |
openshift_logging pattern
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
If enabled, tho logs are stored in ES' operations index, accesible only by cluster admins.
|
| | |
|
| |
|
|
|
|
|
|
| |
Without that, playbook runs print warnings such as this:
[WARNING]: when statements should not include jinja2 templating
delimiters such as {{ }} or {% %}. Found: {{ g_etcd_hosts is not
defined and g_new_etcd_hosts is not
defined}}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of the `openshift_logging_use_mux_client` boolean parameter,
use `openshift_logging_mux_client_mode` which will allow us to support
different mux client use cases:
The value `maximal` will cause Fluentd to perform as much of the
processing as possible at the local node. This currently means all of
the processing *except* for the Kubernetes metadata processing, which will
be done by mux. This is the currently recommended mode to use due to
current scaling issues.
The value `minimal` means that Fluentd will do *no* processing at all,
and send the raw logs to mux for processing. This is currently not
recommended to use due to current scaling issues. Ansible will warn
you if you try to use this mode.
`MUX_ALLOW_EXTERNAL` is no longer needed in the mux dc. mux now always
operates to process external logs. The ansible setting
`openshift_logging_mux_allow_external` is still required in order to
set up the mux service to accept connections from outside of the
cluster.
|
| |
|
|
|
|
|
|
|
|
| |
"openshift_logging_fluentd_use_journal=false" nor omitted collects the log entries
https://bugzilla.redhat.com/show_bug.cgi?id=1466152
Do not set openshift_logging_fluentd_use_journal or USE_JOURNAL at
all unless it is explicitly set as an ansible param. It is almost
always better to let fluentd figure out which log driver docker
is using.
|
| | |
|
| | |
|
| | |
|
| |
|
