Description of problem: To have a simple HE setup flow, it should be possible to install the Engine appliance (rpm) from within Cockpit with just the click of a button. HE setup will then pick up the installed appliance. Thsi way the user does not need to care where to get the appliance from.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
Instead of doing this in the Cockpit implementation, this should be done as part of hosted-engine --deploy. In this case users using the cli will also benefit from the enhancement.
*** Bug 1334653 has been marked as a duplicate of this bug. ***
Ping. Any progress here?
(In reply to Ryan Barry from comment #5) > Ping. Any progress here? No, we need to discuss what is the best solution for your use case, as, from our last discussion, it seems that just allowing installation of appliance in hosted-engine setup is not going to be enough, if I understood correctly. Fabian?
Fabian is on PTO for the next couple of weeks... From my perspective, allowing installation of appliance in hosted-engine-setup should be enough (ideally with a flag to hosted-engine-setup which allows prefetching the appliance). What's missing from that workflow?
(In reply to Ryan Barry from comment #7) > Fabian is on PTO for the next couple of weeks... > > From my perspective, allowing installation of appliance in > hosted-engine-setup should be enough (ideally with a flag to > hosted-engine-setup which allows prefetching the appliance). What's missing > from that workflow? IIRC the issue was related to cockpit session timeout handling, then fabian said that this would need to be implemented in another way, that would be discussed later. Another issue is that we can't ask setup questions before otopi runs its "install packages" stage, that is something required to implement properly the flow you want.
(In reply to Rafael Martins from comment #8) > IIRC the issue was related to cockpit session timeout handling, then fabian > said that this would need to be implemented in another way, that would be > discussed later. Actually this might be a problem also in other parts of the flow - IIRC we already saw it happens. Not sure what's the best solution, it might be needed to have something on the server that maintains state and can allow cockpit to reconnect and update its view etc. Either otopi itself or some other thing. No idea how cockpit in general works, or our plugin, so might not be relevant. > Another issue is that we can't ask setup questions before > otopi runs its "install packages" stage, that is something required to > implement properly the flow you want. That's not accurate. We *try* to ask all questions during customization stage, but can also ask earlier. E.g. we do already ask in hosted-engine-setup 'Are you sure you want to continue?' in stage SETUP. And IIUC your pending patch [1] should allow installing packages whenever we want - although without rollback (but also "internal packages" has no rollback). [1] https://gerrit.ovirt.org/57785
(In reply to Yedidyah Bar David from comment #9) > Actually this might be a problem also in other parts of the flow - IIRC we > already saw it happens. Not sure what's the best solution, it might be > needed to have something on the server that maintains state and can allow > cockpit to reconnect and update its view etc. Either otopi itself or some > other thing. No idea how cockpit in general works, or our plugin, so might > not be relevant. cockpit is working here by spawning a process and attaching to stdin/stdout. It's javascript (running through a service proxy on the host), so it goes away if the session times out our the page is refreshed. There's been some discussion about spawning hosted-engine-setup inside tmux/screen in the background to reattach later, but there's not a strong use case for it without regular session timeouts (which there aren't in the current flow). otopi providing a native way to do this would be far preferable if we were to go that route, I think.
*** This bug has been marked as a duplicate of bug 1349301 ***