Provide an indication to HE VM that it is HE VM. Right now, there is no indication on HE VM that it is the manager. But having it would be extremely useful. Especially for the support team, working with customer backups and understanding customers' setups.
Another, less optimal, option is to make sure rhevm appears in the list of applications of that VM. But this will also require running guest agent on the manager. And if the agent is not installed, that information would be unavailable.
(In reply to Marina from comment #1) what kind of indication do you have in mind for the ideal case? > Another, less optimal, option is to make sure rhevm appears in the list of > applications of that VM. that would be easy to add > But this will also require running guest agent on > the manager. And if the agent is not installed, that information would be > unavailable. the guest agent should be a mandatory running service for HE, if it is not already
(In reply to Michal Skrivanek from comment #2) > (In reply to Marina from comment #1) > > what kind of indication do you have in mind for the ideal case? Something in the UI, that once I look into it, I'd be able knowing right away which vm is the hosted engine. Maybe like the crown we have for the mgmt logical network? > > > Another, less optimal, option is to make sure rhevm appears in the list of > > applications of that VM. > > that would be easy to add > > > But this will also require running guest agent on > > the manager. And if the agent is not installed, that information would be > > unavailable. > > the guest agent should be a mandatory running service for HE, if it is not > already I don't know. I went through the HE guide[1] and I didn't find how to configure non-appliance RHEV-M. So, I could not see anywhere that the agent is required. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Self-Hosted_Engine_Guide/chap-Introduction.html
Another scenario when such indication is needed: many times in the guides we suggest to put HE VM into maintenance through the admin portal. But if the VM does not have the default name "HostedEngine", which is quite possible, and if it is a new sys admin managing that environment, that person would have no clue which VM to use to set the maintenance through UI.
On the same note, please tell me if I should open another RFE for this or you can handle this here: It should also indicate if HE setup in global maintenance or not. Right now there is no indication and both options are available: - Enable Global HA maintenance - Disable Global HA maintenance. And seems like we can click on them both multiple times. I think we should gray out the option that is not available.
(In reply to Marina from comment #5) > On the same note, please tell me if I should open another RFE for this or > you can handle this here: > It should also indicate if HE setup in global maintenance or not. Right now > there is no indication and both options are available: > - Enable Global HA maintenance > - Disable Global HA maintenance. > And seems like we can click on them both multiple times. > > I think we should gray out the option that is not available. And add indication of the status on the portal, together with the indication of the HE VM.
We need to extend this RFE to the hosts and cluster as well.
Another scenario - in case of RHEV-H, there is no way to know if it is a hosted engine setup or not, since no UI indication + ha packages are installed on RHEV-H by default.
Changing bug title to a more global name. Currently, UI is lacking any notification on HE setup. - HE VM should have indicator - HE hosts/cluster should have indicators - [HE storage?] - HA packages should be presented under software information on the host - Global/local maintenance indication is missing and more.
moving to Integration since the RFE is about improving global HE experience
Action item is to discuss this with integration and UX team to make sure all aspects of the CLI are represented in the UI and that actions completion and state are clear. When do you think this will be assigned to some to start this process?
Andrej, we just need to figure out what we are missing for now, no implementation will be involved just yet.
The CLI has the following commands, some of them can be done in the engine: --deploy [options] - can be done in engine --vm-start --vm-start-paused --vm-shutdown --vm-poweroff --vm-status [--json] - most of the info can be accessed in engine --add-console-password [--password=<password>] --check-deployed --check-liveliness --connect-storage --console --set-maintenance --mode=<mode> - can be done in engine --reinitialize-lockspace --clean-metadata --upgrade-appliance --rollback-upgrade The --vm-status command returns this information per host: - live-data - true if host is running - hostname - host-id - sqeuence number of host, probably not exposed to engine - engine-status - status of the engine VM and optional reason - score - stopped - both are in the webadmin in "general" subtab for a host, as "Hosted Engine HA:" - local maintenance - can be seen in the engine as normal maintenance - crt32 - host timestamp - extra - more info as a string It also shows if the HE is in global maintenance. In the webadmin, global maintenance can be seen under "general" subtab for a host, as "Hosted Engine HA:"
(In reply to Andrej Krejcir from comment #19) > The CLI has the following commands, some of them can be done in the engine: > --deploy [options] > - can be done in engine It currently not complete. See BZ #1369827. > > --vm-start > --vm-start-paused > --vm-shutdown > --vm-poweroff I don't expect to be able to do this via UI\REST. > > --vm-status [--json] > - most of the info can be accessed in engine > > --add-console-password [--password=<password>] > --check-deployed > --check-liveliness > --connect-storage > --console These are probably not relevant after initial deployment or only when troubleshooting from the host. > > --set-maintenance --mode=<mode> > - can be done in engine The main problem here is that the buttons do not reflect the state for global maintenance. There is no way to know if this action worked or not from the UI. For local maintenance the host maintenance should trigger this, so probably good there. > > --reinitialize-lockspace > --clean-metadata > --upgrade-appliance > --rollback-upgrade All of these are not relevant for when the appliance is up. > > The --vm-status command returns this information per host: > > - live-data > - true if host is running > > - hostname > > - host-id > - sqeuence number of host, probably not exposed to engine > > - engine-status > - status of the engine VM and optional reason > > - score > - stopped > - both are in the webadmin in "general" subtab for a host, > as "Hosted Engine HA:" > > - local maintenance > - can be seen in the engine as normal maintenance > > - crt32 > - host timestamp > > - extra > - more info as a string Any info that we might need in the UI? > > It also shows if the HE is in global maintenance. > In the webadmin, global maintenance can be seen under > "general" subtab for a host, as "Hosted Engine HA:" We should probably have the engine UI should something more general to note this fact, but this is good enough for now. I will open RFEs for this and the other issues mentioned above: - Adding crown to HE VM. - HE hosts should have indicators and a way to filter them from the rest of the hosts. - HE storage should have a crown. - Global maintenance clear indication, set confirmation and stateful button.
(In reply to Yaniv Dary from comment #20) > > - extra > > - more info as a string > > Any info that we might need in the UI? > No, most of the info is in other fields too. For example, this 'extra' string is on my setup: metadata_parse_version=1 metadata_feature_version=1 timestamp=1201239 (Thu Oct 27 11:01:59 2016) host-id=1 score=3400 maintenance=False state=EngineUp stopped=False
The extra section is a bit tricky though, it is not required to be machine readable, up-to-date or valid. Hosted engine does its best, but the only reliable data block used for synchronization is the one we get the non-extra arguments from. We might not need such high guarantees for UI indications though and in that case the state might be something to expose. It needs a translation layer though as it directly reflects the name of the active hosted engine agent state class (the names or the state machine flows can change as they are implementation specific).
btw any update re guest agent being present in appliance? (comment #3)
(In reply to Michal Skrivanek from comment #24) > btw any update re guest agent being present in appliance? (comment #3) If it's in the appliance, it always there, since this is the only supported option since 4.0.
All depends on bug verified - we can close this Tracker.
Setting requires_doc_text to -, because the Release Notes text will be covered by bug 1367924.