That issue demonstrates that is is possible, during a UI cluster deployment, to select "LogSearch" as a service, but not select "Ambari-Infra". The UI then continues through the wizard, without requiring any additional LogSearch configuration.
LogSearch has been updated to allow for external SolrCloud deployments as well as internally-managed SolrCloud deployments, so the original dependency in the stack had to be removed to support this deployment mode.
That being said, the default behavior in the UI deployment should still encourage most users to accept the default behavior, meaning that the Ambari-Infra service should be included.
Currently, if Ambari-Infra is not selected, the deployment will fail, since the wizard does not require either selecting Ambari-Infra or configuring the location of the external SolrCloud instance.
I ran a test by selecting Atlas without selecting Ambari-Infra (which is a similar deployment case, since Atlas can use an internal or external SolrCloud deployment), and found that in the Atlas case the UI pops up a "Limited Functionality Warning" if Ambari-Infra is not selected.
We should implement this for LogSearch as well, so that if the user selects LogSearch, but does not select Ambari-Infra, then a LogSearch-specific limited functionality warning pops up, to let the user know that this is not default scenario, and will require further configuration.
This work would involve two tasks:
1. If the user selects LogSearch, then Ambari-Infra should be auto-selected by default.
2. Adding the "Limited Warning Functionality" popup to the wizard, if LogSearch is selected without Ambari-Infra.
3. If the user receives this popup and chooses to proceed anyway, the configuration wizard should enforce the configuration of the external SolrCloud instance.
I took a quick look at the ambari-web code, and it looks like something similar to #2 is implemented in the step4_controller.js:
It's likely that we can reuse this approach for LogSearch as well.