Description of problem: Since after setup hosted engine successfully in rhevh ,couldn't reset hosted engine again. So better to disable <Setup Hosted Engine> button of Hosted Engine page after configured hosted engine success Version-Release number of selected component (if applicable): rhev-hypervisor6-6.6-20150312.0 ovirt-node-3.2.1-10.el6.noarch ovirt-hosted-engine-ha-1.2.5-1.el6ev.noarch ovirt-node-plugin-hosted-engine-0.2.0-10.0.el6ev.x86_64 ovirt-hosted-engine-setup-1.2.2-1.el6ev.noarch ovirt-host-deploy-1.3.0-2.el6ev.noarch rhevm-appliance-20150129.0-1.x86_64.rhevm.ova rhevm vt14 (3.5.1-0.1.el6ev) How reproducible: 100% Steps to Reproduce: 1. Install rhev-hypervisor6-6.6-20150312.0 2. Enter Hosted Engine Setup menu and completed the configuration. Actual results: After step2, <Setup Hosted Engine> button still could enable Expected results: Disable <Setup Hosted Engine> button after setup hosted engine successfully Additional info: ..
Currently hosted-engine-setup itself does not detect this case, thus I'm moving this to hosted-engine-setup for consideration. Once this is implemented there RHEV-H will inherit this behavior.
Sandro is the current issue specific to node or is it a generic HE issue?
It's a specific issue of node since the request is to disable the button within the TUI. But it relies on having the setup or another tool to be able to tell back to the TUI if it can work or not in order to enable / disable it.
Sandro, is there an easy way to tell by an API call or call of a command if hosted-engine is already set up?
(In reply to Fabian Deutsch from comment #7) > Sandro, is there an easy way to tell by an API call or call of a command if > hosted-engine is already set up? Can you please elaborate? Isn't hosted-engine --check-liveliness enough to tell if the hosted engine is up and running? Or do you need something that tell you about the configuration only, even if the engine is not up?
Sure. In this bug we need to know if the hosted-engine was already configured before or not - to show this information in the TUI.
Do we actually need this for the Cockpit HE functionality?
Basically yes. When opening the hosted engine page, it currently just prompts for setup. It would be desirable to present different information if it's deployed already (changing maintenance modes, status, etc. Without this, the only way to check whether it's deployed is to try some other command (--vm-status, for example), and check both the exit code and output of that command to find out whether it exited 1 because it hasn't been deployed yet or because something went wrong. This keeps too much state about how hosted engine works in a front-end to the utility. Requiring thus for the cockpit plugin isn't strictly necessary (everything can always be worked around), but is the right way to do it.
Indeed, this sounds like the right way. Let's see if it can be fixed on the way.
Several questions from the QA side: 1)Is this only TUI issue? 2)Is this only RHEVH related issue? 3)Is this fix relevant in case of Cockpit replaces TUI in 4.0? 4)Isn't solution provided in https://bugzilla.redhat.com/show_bug.cgi?id=1324921 sufficient for this bug? Something like "Check on host that there is no hosted-engine have been deployed yet by running "hosted-engine --check-deployed" command.", so in case of RHEVH is already part of HE deployment, than simply return the status back to TUI and make "<Setup Hosted Engine> button" grayed out?
Is there RHEVH available for 4.0?
(In reply to Nikolai Sednev from comment #13) > Several questions from the QA side: > 1)Is this only TUI issue? This doesn't affect the TUI in legacy RHEV-H. It's just for new feature development. Legacy RHEV-H already queries whether the engine is deployed by using the HAClient Python bindings. > 2)Is this only RHEVH related issue? Yes, this is only for the next-generation hypervisor. > 3)Is this fix relevant in case of Cockpit replaces TUI in 4.0? Yes. > 4)Isn't solution provided in > https://bugzilla.redhat.com/show_bug.cgi?id=1324921 sufficient for this bug? > Something like "Check on host that there is no hosted-engine have been > deployed yet by running "hosted-engine --check-deployed" command.", so in > case of RHEVH is already part of HE deployment, than simply return the > status back to TUI and make "<Setup Hosted Engine> button" grayed out? Yes and no. We're also tracking bz#1324923 for the other half of this. Since that patch also has positive code review, we'll ideally get both into the next tech preview, and both will definitely be in 4.0. With that in, the logic will look like: Open Hosted Engine Page Verify "--check-deployed" If it hasn't been deployed, show the setup splash If it has been deployed, show a different page, which has hosted engine status, buttons for changing maintenance mode, etc. We need bz#1324923 on MODIFIED to implement this. (In reply to Nikolai Sednev from comment #14) > Is there RHEVH available for 4.0? The state of the 3.6.6 tech preview for RHEVH is essentially the "working" 4.0 build right now. We'll hopefully do a fresh 4.0 build in the coming week, with the tech preview handed over.
There are upstream builds available: http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0_build-artifacts-fc22-x86_64/
I've just installed a fresh CentOS Linux release 7.2.1511 (Core) on one of my hosts and deployed HE on it successfully, but neither "hosted-engine --check-deployed" via CLI shown me something at all, nor the WEBUI of the Cockpit indicates that HE is deployed, the opposite, it shows that HE deployment is possible and lets me the option to start the deployment. Host: mom-0.5.3-1.1.el7.noarch vdsm-4.17.999-1155.gitcf216a0.el7.centos.x86_64 qemu-kvm-tools-ev-2.3.0-31.el7_2.10.1.x86_64 libvirt-daemon-1.2.17-13.el7_2.4.x86_64 libvirt-lock-sanlock-1.2.17-13.el7_2.4.x86_64 qemu-kvm-ev-2.3.0-31.el7_2.10.1.x86_64 sanlock-lib-3.2.4-2.el7_2.x86_64 sanlock-python-3.2.4-2.el7_2.x86_64 libvirt-client-1.2.17-13.el7_2.4.x86_64 libvirt-daemon-driver-nwfilter-1.2.17-13.el7_2.4.x86_64 libvirt-daemon-driver-secret-1.2.17-13.el7_2.4.x86_64 libvirt-daemon-driver-interface-1.2.17-13.el7_2.4.x86_64 qemu-img-ev-2.3.0-31.el7_2.10.1.x86_64 libvirt-daemon-driver-qemu-1.2.17-13.el7_2.4.x86_64 libvirt-daemon-kvm-1.2.17-13.el7_2.4.x86_64 libvirt-python-1.2.17-2.el7.x86_64 libvirt-daemon-config-nwfilter-1.2.17-13.el7_2.4.x86_64 libvirt-daemon-driver-nodedev-1.2.17-13.el7_2.4.x86_64 qemu-kvm-common-ev-2.3.0-31.el7_2.10.1.x86_64 libvirt-daemon-driver-network-1.2.17-13.el7_2.4.x86_64 sanlock-3.2.4-2.el7_2.x86_64 libvirt-daemon-driver-storage-1.2.17-13.el7_2.4.x86_64 ovirt-vmconsole-host-1.0.2-0.0.master.20160517094103.git06df50a.el7.noarch ovirt-setup-lib-1.0.2-0.0.master.20160502125738.gitf05af9e.el7.centos.noarch ovirt-release40-4.0.0-0.3.beta1.noarch ovirt-vmconsole-1.0.2-0.0.master.20160517094103.git06df50a.el7.noarch ovirt-engine-sdk-python-3.6.5.1-0.1.20160507.git5fb7e0e.el7.centos.noarch ovirt-host-deploy-1.5.0-0.1.alpha1.el7.centos.noarch ovirt-hosted-engine-setup-2.0.0-0.1.beta1.el7.centos.noarch ovirt-release-host-node-4.0.0-0.3.beta1.el7.noarch ovirt-hosted-engine-ha-2.0.0-0.1.beta1.el7.centos.noarch ovirt-node-ng-image-update-placeholder-4.0.0-0.3.beta1.el7.noarch CentOS Linux release 7.2.1511 (Core) Linux 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Engine: rhevm-setup-plugins-4.0.0-0.3.alpha.el7ev.noarch rhevm-dependencies-4.0.0-0.1.alpha.git9ae0cc3.el7ev.noarch rhevm-4.0.0-0.6.master.el7ev.noarch rhevm-doc-3.6.0-7.el6eng.noarch rhevm-branding-rhev-4.0.0-0.0.master.20160219183625.el7ev.noarch Red Hat Enterprise Linux Server release 7.2 (Maipo) Linux 3.10.0-327.22.1.el7.x86_64 #1 SMP Mon May 16 13:31:48 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux Any suggestions?
(In reply to Nikolai Sednev from comment #17) > I've just installed a fresh CentOS Linux release 7.2.1511 (Core) on one of > my hosts and deployed HE on it successfully, but neither "hosted-engine > --check-deployed" via CLI shown me something at all, nor the WEBUI of the > Cockpit indicates that HE is deployed, the opposite, it shows that HE > deployment is possible and lets me the option to start the deployment. > Any suggestions? This is expected from ovirt-hosted-engine-setup. The return code from --check-deployed should be 0 if it's deployed. If "--check-deployed" is run before deployment happens, you'll get an error. There are two steps here: One is for the legacy RHEV hypervisor, which does not depend on --check-deployed (and which this bug was filed against, it looks like). I'll check on a build of the legacy hypervisor, but legacy RHEV-H will not be shipped in 4.0 in any case. The other is for cockpit. Currently, we have bz#1318415 Implementation of that is waiting for both the blockers (--check-deployed and --vm-status --json, which is still in post). I was hoping both would merge around the same time, which would allow us to present a "real" alternate page for hosted engine (where, if hosted engine is deployed, we can query information from --vm-status --json and render and actual alternative which allows for maintenance modes/etc). As an intermediary step, if --json takes much longer to merge, I'll push a patch which at least disables setup if --check-deployed is valid. For verification of this bug, all that's needed is to ensure that --check-deployed outputs a message *before* hosted-engine --deploy is run, and that "hosted-engine --check-deployed && echo $?" is 0.
So currently this bug not actually can be verified, right? May we change it from ON_QA to some other state?
(In reply to Nikolai Sednev from comment #19) > So currently this bug not actually can be verified, right? May we change it > from ON_QA to some other state? I got this confused with bz#1324921 when commenting yesterday, so let me try to clear it up. I think the question here is: "What steps are necessary to reproduce this bug?" It was reported against the legacy RHEV Hypervisor, but I can't reproduce it there at all, and it's probably against the wrong component now (this should be ovirt-node if it's still reproducible). The comments here have gotten muddled with bz#1324921, so the state of this bug is essentially: * Filed against the legacy RHEV Hypervisor * Moved to ovirt-hosted-engine-setup * A different bug (bz#1324921) is opened against ovirt-hosted-engine-setup to track the feature needed (for cockpit), but that bug was not set to block this one. That bug is now VERIFIED. From here, there are two possible paths: * The bug is tested against the legacy hypervisor, and moved back to that component for consideration * This bug is closed as a duplicate of bz#1324921 or WONTFIX Fabian, Ying, any thoughts?
(In reply to Ryan Barry from comment #20) > From here, there are two possible paths: > > * The bug is tested against the legacy hypervisor, and moved back to that > component for consideration No need, because we will only fix urgent bug in vintage node, but this bug is low severity. > > * This bug is closed as a duplicate of bz#1324921 or WONTFIX > > Fabian, Ying, any thoughts? Ryan, our goal of this bug is to let user know the HE status in UI to _avoid_ deploying HE again if it is running. Now we can move this bug back to Node component, and update the bug summary to "Disable "start" button to protect HE re-deploy", OR if we would like to dup this bug, it should be closed as a duplicate of bz #1318415 instead of bz #1324921, and also need to add one more requirement in bz #1318415 to let user can not click the "start" button if HE is deployed. Currently we are in ovirt-3.6 branch, rhevh-ng does not include ovirt-hosted-engine-setup 4.0 package(ovirt-hosted-engine-setup-2.0.0-0.1.beta1.el7 of bug 1324921), can not test this ON_QA bug.
[adding Fabian needinfo back for comment 20]
To me it would be fine to close this bug as a dupe of bz #1324921. Both are about checking if HE was already run or not.
*** This bug has been marked as a duplicate of bug 1324921 ***