Bug 1422356 - Gluster: Cockpit UI times out and cannot resume
Summary: Gluster: Cockpit UI times out and cannot resume
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: cockpit-ovirt
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Gobinda Das
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-15 05:46 UTC by Laura Bailey
Modified: 2022-05-06 08:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-21 06:39:55 UTC
oVirt Team: Gluster
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-45941 0 None None None 2022-05-06 08:35:36 UTC

Description Laura Bailey 2017-02-15 05:46:59 UTC
If the connection to the cockpit UI is lost, the cockpit UI times out.

There's no way to resume previous activity (e.g. continuing to run gdeploy to deploy gluster nodes) after a reboot or when the connection comes back.

We should have some way to store and recover state after disconnect and reconnect.

Comment 1 Ryan Barry 2017-02-15 13:47:00 UTC
I would then ask what happens if the system suffers power loss (or another catastrophic failure).

We can use a fifo or a named pipe or one of any number of methods to communicate. 

Hosted Engine is a connection to stdin/stdout of the ovirt-hosted-engine-setup process. 

Unfortunately, there's no API we can use to set all of these values (some of what we want is targeted for later releases, some we'll probably never get). Doing validation of whether or not a given NFS export is actually usable by vdsm, for example, cannot be moved to an API we can consume (and receive validation about) without building a new package from scratch simply to support this.

But a user who starts deployment then leaves the page would currently leave a copy of ovirt-hosted-engine-setup running in the background. If they then deploy from the CLI (because ovirt-hosted-engine-setup allows multiple running copies), should it start from where they were in cockpit?

If they complete deployment on the CLI and connect to cockpit again, then finish the deployment with different options, which one wins?

Due to the lack of an API we can actually use, making connecting to stdin/stdout a requirement, doing this is extremely tricky. The gdeploy plugin is much simpler to do this with, but this will likely not be fixed for oVirt Hosted Engine until we get better backend support.

Comment 2 Sahina Bose 2017-11-21 06:39:55 UTC
Closing this until we have backend support in Cockpit to achieve this


Note You need to log in before you can comment on or make changes to this bug.