| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit relocates filter_plugings to lib_utils,
changes the namespacing to prevent unintended use of
older versions that may be present in filter_plugins/
directory on existing installs.
Add lib_utils to meta depends for roles
Also consolidate some plugins into lib_utils from
various other areas.
Update rpm spec, obsolete plugin rpms.
|
|
|
|
| |
at the end of a deployment, allowing for override with variable
|
| |
|
| |
|
|
|
|
|
| |
- all images logging and metrics change their default imagePullPolicy
from Always to IfNotPresent
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Automatic merge from submit-queue.
Bug 1496271 - Perserve SCC for ES local persistent storage
ES can be modified to use node local persistent storage. This requires changing SCC and is described in docs:
https://docs.openshift.com/container-platform/3.6/install_config/aggregate_logging.html
During an upgrade, SCC defined by the user is ignored. This fix fetches SCC user defined as a fact and adds it to the ES DC which is later used.
Also includes cherrypicked fix for - Bug 1482661 - Preserve ES dc nodeSelector and supplementalGroups
cc @jcantrill
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ES can be modified to use node local persistent storage. This requires
changing SCC and is described in docs:
https://docs.openshift.com/container-platform/3.6/install_config/aggregate_logging.html
During an upgrade, SCC defined by the user is ignored. This fix fetches
SCC user defined as a fact and adds it to the ES DC which is later used.
|
| |
| |
| |
| | |
(cherry picked from commit 601e35cbf4410972c7fa0a1d3d5c6327b82353ac)
|
|/ |
|
|\
| |
| | |
Merged by openshift-bot
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/| |
logging set memory request to limit
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
creeping
|
|
|
|
|
|
|
|
|
|
| |
The readiness probe, as currently implemented, together with the ES
master discovery using the logging-es service, causes a deadlock on
clusters with more than one node. Readiness probe will be
reintroduced in later release.
More information in:
https://bugzilla.redhat.com/show_bug.cgi?id=1459430
|
|\
| |
| | |
logging: write ES heap dump to persistent storage
|
| | |
|
|\ \
| | |
| | | |
bugzilla:1463577 - Fix for dynamic pvs when using storageclasses.
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Merged by openshift-bot
|
| |/ |
|
|\ \
| | |
| | | |
Merged by openshift-bot
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bug 1460564. Fixes [BZ #1460564](https://bugzilla.redhat.com/show_bug.cgi?id=1460564).
Unfortunately, the defaults for Elasticsearch prior to v5 allow more
than one "node" to access the same configured storage volume(s).
This change forces this value to 1 to ensure we don't have an ES pod
starting up accessing a volume while another ES pod is shutting down
when reploying. This can lead to "1" directories being created in
`/elasticsearch/persistent/${CLUSTER_NAME}/data/${CLUSTER_NAME}/nodes/`.
By default ES uses a "0" directory there when only one node is accessing
it.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
port the code that creates the external Elasticsearch routes to the
new logging roles
Have to suppress this error message:
SSL Problem illegal change cipher spec msg, conn state = 6, handshake state = 1
which is coming from the router health check, until
https://github.com/openshift/origin/issues/14515
is fixed - otherwise, the es log is spammed relentlessly
|
|\
| |
| | |
Merged by openshift-bot
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we currently create the set of logging `DeploymentConfig`s, we
create them with zero desired replicas. This causes the deployment to
immediately succeed as there is no work to be done. This inhibits our
ability to use nice CLI UX features like `oc rollout status` to monitor
the logging stack deployments. Instead, we should can create the configs
with the correct number of replicas in the first place and stop using
`oc scale` to bring them up after the fact.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
|
| |
|
| |
|
| |
|
|
|