Uploaded image for project: 'AeroGear'
  1. AeroGear
  2. AEROGEAR-8076

Spike: make ES and Kibana calls within an operator vs APB

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • None
    • None
    • None

      Documentation on Data Sync audit logs and metrics with OpenShift logging: https://docs.google.com/document/d/1hrVkcY4YHkDiUVtXsVMcY_KVR8OWWlMncKAAZfDDm5U/edit

      We would like to have ES mappings and Kibana dashboards ready when the Sync is running within a cluster that has logging enabled.

      How do we do this?

      ES mappings and Kibana saved objects (saved searches, visualizations and dashboards) all have to be stored within some namespace which should be on OpenShift project level. (and even user level, see TODO for that)

      So, the OpenShift project name should be known by the process (APB/Operator/whatever).

      We will call Kibana's REST api to create the saved searches and the dashboards. But how/when to call that REST api is something we need to think about.

      We can call Kibana's REST api:
      a. In sync apb
      b. With an operator
      c. Manually with an Ansible playbook

      And, imagine these cases:

      • Case#1: OpenShift logging is already enabled, provisioning sync afterwards
      • Case#2: OpenShift logging is not enabled, provisioned sync already, enabling logging afterwards

      (a) seems to be simplest way and it works fine in case#1. But it won't work in case#2.
      (b) would also work in case#1 without hassle. But the operator idea is actually there for case#2 so that we can monitor logging related resources and call the REST api once logging is enabled. There are bunch of things unknown yet: permissions, fully automatic / semi automatic, ...
      (c) if that's ok we could ask users to run an Ansible playbook manually at least for case#2.

      These all depend on product team's input on how important it is to handle case#2 automatically. If this is a rare thing and it is ok to do some manual work, (c) is probably the best.

            weil@redhat.com Wei Li (Inactive)
            aliok@redhat.com Ali Ok
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: