summaryrefslogtreecommitdiffstats
path: root/roles/openshift_logging_kibana
Commit message (Collapse)AuthorAgeFilesLines
* Updated to using oo_random_word for secret genewolinetz2017-06-081-2/+2
|
* Updating kibana to store session and oauth secrets for reuse, fix ↵ewolinetz2017-06-082-18/+44
| | | | oauthclient generation for ops
* Updating Kibana-proxy secret key name, fixing deleting secrets, fixed extra ↵ewolinetz2017-05-311-2/+2
| | | | ES dc creation
* Fixing tux warnings and some final clean upewolinetz2017-05-231-11/+11
|
* Appease travisScott Dodson2017-05-221-4/+4
|
* Add a readiness probe to the Kibana containerSteve Kuznetsov2017-05-221-0/+7
| | | | | | | | | In order to ensure that the Kubernetes machinery can determine when the Kibana Pods are becoming ready, we need to add a readiness probe to the Containers that make up those pods. The Kibana readiness probe simply hits the base URL at `http://localhost:5601/` and expects a 200. Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
* Create logging deployments with non-zero replica countsSteve Kuznetsov2017-05-222-10/+2
| | | | | | | | | | | | 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>
* Pulling changes from master branchewolinetz2017-05-222-2/+29
|
* Pulling in changes from masterewolinetz2017-05-221-2/+20
|
* Decomposing openshift_logging role into subcomponent rolesewolinetz2017-05-228-0/+464
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 11:31:22 +0000