Description of problem: $Subject. This is currently planned to be handled by common-logging, see [1]. Another option might be [2]. [1] https://github.com/openshift/openshift-ansible/tree/master/roles/openshift_hosted_logging [2] https://github.com/centos-opstools/opstools-ansible
Opening this bug mainly for tracking. It might be eventually a doc bug, at least for 4.1.
Provide infra to ask the user about: - Fluentd server - Certificate? - Project name - Elastic endpoint (if different than Fluentd server) - Kibana URL - Kibana credentials? (if not supporting SSO?)
The intention of current bug was to install, not to integrate. Since we decided that we'll rely on ocp+cl for this, we should probably either change some fields above to let them own it, or, if they track their work using other means, add a link there. For integration, at the time, I filed bug 1405809. Eventually we decided to require the user to set these params manually, as described there and in bug 1405813 comment 1. If you want an interactive tool for this, it might make sense to open a new bug for it. (In reply to Yaniv Kaul from comment #2) > Provide infra to ask the user about: > - Fluentd server > - Certificate? > - Project name > - Elastic endpoint (if different than Fluentd server) IIUC the engine needs to know about these, in 4.2, as it needs to connect there. So we probably need to restart it when configuring. So it might make sense to add this as a plugin to engine-setup, not a separate tool. > - Kibana URL I guess we might want/need this at some point to add links from the web admin to there, to show stats about entities etc., similarly to what we had with Reports. Do we already have a bz for this? > - Kibana credentials? (if not supporting SSO?) I think that's a different discussion. If/when we add links to kibana in the ui, and do not have SSO, we should probably allow the user to decide whether to provide creds during this point (engine-setup) and have them saved on engine machine, and having all users use same creds, or to provide creds from the web interface, which will be saved in the browser/session. Or some other means.
(In reply to Yedidyah Bar David from comment #3) > The intention of current bug was to install, not to integrate. Since we > decided that we'll rely on ocp+cl for this, we should probably either change > some fields above to let them own it, or, if they track their work using > other means, add a link there. > > For integration, at the time, I filed bug 1405809. Eventually we decided to > require the user to set these params manually, as described there and in bug > 1405813 comment 1. So we either need some nicer interface or leave as is - but we are not planning to install ocp+cl right now. We may bring an Ansible script that does that, for example, as VMs on top of RHV. > > If you want an interactive tool for this, it might make sense to open a new > bug for it. > > (In reply to Yaniv Kaul from comment #2) > > Provide infra to ask the user about: > > - Fluentd server > > - Certificate? > > - Project name > > - Elastic endpoint (if different than Fluentd server) > > IIUC the engine needs to know about these, in 4.2, as it needs to connect > there. > So we probably need to restart it when configuring. So it might make sense > to add this as a plugin to engine-setup, not a separate tool. This was my intention when I read this bug. > > > - Kibana URL > > I guess we might want/need this at some point to add links from the web > admin to there, to show stats about entities etc., similarly to what we had > with Reports. Do we already have a bz for this? No, not yet. > > > - Kibana credentials? (if not supporting SSO?) > > I think that's a different discussion. If/when we add links to kibana in the > ui, and do not have SSO, we should probably allow the user to decide whether > to provide creds during this point (engine-setup) and have them saved on > engine machine, and having all users use same creds, or to provide creds > from the web interface, which will be saved in the browser/session. Or some > other means. Right. I'd like to believe SSO is a good path to pursue, though. Keeping credentials is annoying, as it's a copy of them, and you need to update them, etc.
Yaniv - please provide the requirement for the integration.
(In reply to Yaniv Kaul from comment #5) > Yaniv - please provide the requirement for the integration. I see this as a configuration option for the host metrics agents via the UI\REST. Allow setting different parameters that will be used by the engine side Ansible script.
(In reply to Yaniv Lavi from comment #6) > (In reply to Yaniv Kaul from comment #5) > > Yaniv - please provide the requirement for the integration. > > I see this as a configuration option for the host metrics agents via the > UI\REST. We don't have configuration options exposed via UI and/or REST (for example, none of the engine-config values are) > Allow setting different parameters that will be used by the engine side > Ansible script. They are in a standard config file which is easily modifiable via Ansible.
(In reply to Yaniv Kaul from comment #7) > (In reply to Yaniv Lavi from comment #6) > > (In reply to Yaniv Kaul from comment #5) > > > Yaniv - please provide the requirement for the integration. > > > > I see this as a configuration option for the host metrics agents via the > > UI\REST. > > We don't have configuration options exposed via UI and/or REST (for example, > none of the engine-config values are) > > > Allow setting different parameters that will be used by the engine side > > Ansible script. > > They are in a standard config file which is easily modifiable via Ansible. I feel conformable with this as a v1, v1.x can have a Ansible interactive mode that will give wizard experience that we can put into Cockpit as well.
Shirly, please devel-ack based on above v1 requirement (Ansible script, YAML config file based configuration).
Should this be MODIFIED?
(In reply to Yaniv Kaul from comment #9) > Shirly, please devel-ack based on above v1 requirement (Ansible script, YAML > config file based configuration). I'm moving to modified based on the v1 requirements, Ansible script, YAML config file based configuration.
verified in ovirt-engine-metrics-1.1.1-0.0.master.20170919065728.el7.centos.noarch configuration file: -rw-r--r--. 1 root root 895 Sep 21 16:27 /etc/ovirt-engine-metrics/config.yml playbooks to connect to metrics store on top of fluentd: -rwxr-xr-x. 1 root root 145 Sep 19 08:57 /usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_hosts_for_metrics.sh -rwxr-xr-x. 1 root root 2282 Sep 19 08:57 /usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.