Description of problem: The rhevm-setup installer does not prompt the user to install rhevm-reports. This leads to customers perhaps not knowing about rhevm-reports until they need it at which point they will be starting with no data collected. It would be good if rhevm-setup prompted the user to install rhevm-reports and warned them about the additional memory requirements as well. As it stands now, if the user yum installs rhevm-reports on their own, there's no indication that additional memory may be required. Version-Release number of selected component (if applicable): 3.1 How reproducible: Very Steps to Reproduce: 1. yum install rhevm 2. run 'rhevm-setup' Actual results: Install completes without asking the user to install the additional set of packages that comprises rhevm-reports Expected results: Installer should ask the user if they would like to install an additional component, rhevm-reports, and should warn them that additional system memory may be required.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
I suggest we wait for the otopi based reports installer implementation.
Alex - bug is not slated to 3.3 at this point, so is on the wait already. you can add a dependency on the otopi bug directly
Proposing this for 3.4.0 since all dependencies have been fixed.
Now that reports and DWH have been migrated to otopi, we can detect if dwh and reports plugin are there and if not output an informative message about the availability of DWH and reports. Either if it's available or not we can tell the user about the additional memory requirements. Then if missing ask the user to install them and run again setup in a second step or abort so the user can install missing packages and then tun setup again. What we're just missing here is the text we have to output. Yaniv can you detail additional requirements for the message? I assume this message may be useful also on upstream, right?
(In reply to Sandro Bonazzola from comment #12) > Now that reports and DWH have been migrated to otopi, we can detect if dwh > and reports plugin are there and if not output an informative message about > the availability of DWH and reports. > Either if it's available or not we can tell the user about the additional > memory requirements. > Then if missing ask the user to install them and run again setup in a second > step or abort so the user can install missing packages and then tun setup > again. > > What we're just missing here is the text we have to output. > Yaniv can you detail additional requirements for the message? > I assume this message may be useful also on upstream, right? I think this pretty much covers this. Output that this is optional and I would recommend checking that dwh & reports isn't installed remotely. checking lastSync in DWH for non default value and if the reports' redirect is present and non default. Yaniv
(In reply to Yaniv Dary from comment #14) > I would recommend checking that dwh & reports isn't installed remotely. Do we support this configuration or this is in theory?
(In reply to Alon Bar-Lev from comment #15) > (In reply to Yaniv Dary from comment #14) > > I would recommend checking that dwh & reports isn't installed remotely. > > Do we support this configuration or this is in theory? It will be in for 3.5 probably. Yaniv
(In reply to Yaniv Dary from comment #16) > (In reply to Alon Bar-Lev from comment #15) > > (In reply to Yaniv Dary from comment #14) > > > I would recommend checking that dwh & reports isn't installed remotely. > > > > Do we support this configuration or this is in theory? > > It will be in for 3.5 probably. This bug is for 3.4
(In reply to Alon Bar-Lev from comment #17) > (In reply to Yaniv Dary from comment #16) > > (In reply to Alon Bar-Lev from comment #15) > > > (In reply to Yaniv Dary from comment #14) > > > > I would recommend checking that dwh & reports isn't installed remotely. > > > > > > Do we support this configuration or this is in theory? > > > > It will be in for 3.5 probably. > > This bug is for 3.4 I have no problem having this one way in 3.4 and another in 3.5. I would want to save rewrite.
Yaniv, can you detail memory / disk requirements for DWH and reports?
(In reply to Sandro Bonazzola from comment #19) > Yaniv, can you detail memory / disk requirements for DWH and reports? It is very hard to do since it is very dependent on the managed environment size. We asked jasper for guidelines for this and they couldn't provide.
removing UserExperience keyword - no user experience design advice is needed.
According to http://community-static.jaspersoft.com/sites/default/files/docs/jasperreports-server-install-guide.pdf minimum requirements are: disk: 10GB free ram: 3GB recommended requirements are: disk: >= 40GB ram: >= 4GB Let's use those as starting point.
Re-scoping this issue: Since user are able to install reports\dwh on separate server and this is the recommended installation path and since in the future we plan to provide reports and DWH via virtual appliance, we will not suggest to install these package locally. The requirement here is to provide oVirt wiki link\docs to installation of reports and DWH and in the future recommend enabling the appliance from GUI.
(In reply to Yaniv Dary from comment #26) > The requirement here is to provide oVirt wiki link\docs to installation of > reports and DWH and in the future recommend enabling the appliance from GUI. Do we currently have such links? How do we make sure it's persistent / avoid hard-coding it into the installer?
Dynamic links cannot be in the code. So either we have a general statement or find a mechanism to provide something reliable that works even with no connection to the Internet, as I expect many deployments are.
We already provide links in other places in the code, please use the same method to add links to these docs.
Einav, can you advise on comment #32? Didi: looks ok to me.
(In reply to Sandro Bonazzola from comment #33) > Einav, can you advise on comment #32? > Adding Greg. The explanation regarding how the context-sensitive-help documentation-links work sounds correct to me (Greg should confirm). Also, the suggested solution to have the link hard-coded in the setup (preferably in some parameter/conf if possible, obviously) sounds OK.
Didi explained it perfectly!
Verified on 3.6.0-0.0.master.20150510172322.git48679b7.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html