Bug 1295945 - oVirt appliance defaults to applicationMode=virt
oVirt appliance defaults to applicationMode=virt
Product: ovirt-appliance
Classification: oVirt
Component: Core (Show other bugs)
x86_64 Linux
unspecified Severity medium (vote)
: ovirt-3.6.3
: ---
Assigned To: Fabian Deutsch
Pavel Stehlik
: Reopened
: 1295946 (view as bug list)
Depends On:
Blocks: Gluster-HC-1
  Show dependency treegraph
Reported: 2016-01-05 15:57 EST by Charlie Inglese
Modified: 2016-04-07 09:49 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-02 05:10:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Node
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dfediuck: ovirt‑3.6.z?
mgoldboi: planning_ack+
fdeutsch: devel_ack+
rule-engine: testing_ack?

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 52801 master MERGED engine: Use the default application mode (both) 2016-01-27 09:09 EST

  None (edit)
Description Charlie Inglese 2016-01-05 15:57:28 EST
Description of problem:
The oVirt appliance /root/ovirt-engine-answers file only support appliance mode virt.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install oVirt engine appliance
2. Note /root/ovirt-engine-answers variables on ovirt-engine (applicationMode=virt)

Actual results:

Expected results:
applicationMode should be a cloudInit variable that can be passed in using the ovirt-hosted-engine answer file, or at least be defaulted to "Both"

Additional info:
Comment 1 Fabian Deutsch 2016-01-05 16:00:37 EST
Simone, do you have any recommendation for this?
Comment 2 Simone Tiraboschi 2016-01-05 16:26:54 EST
(In reply to Fabian Deutsch from comment #1)
> Simone, do you have any recommendation for this?

I'd suggest simply to have
OVESETUP_CONFIG/applicationMode=str:both in the appliance answerfile.
I'm not sure it's worth to ask at hosted-engine setup and pass it via cloud-init as 'both' could be a reasonable default for everybody.
Comment 3 Charlie Inglese 2016-01-06 10:47:10 EST
*** Bug 1295946 has been marked as a duplicate of this bug. ***
Comment 5 Simone Tiraboschi 2016-01-12 12:46:33 EST
ApplicationMode sets what the user can use the engine for; we have three allowed values here: VirtOnly, GlusterOnly and Both.

The value has an impact in terms of what the user can do both in term of user interface and CanDoAction filters: if the user chooses VirtOnly, all the gluster related options are not present in the GUI and all the gluster related actions are explicitly forbidden if directly called via API.

So, if we change the appliance default from from virt to both, the user will see 'Enable Gluster Service' checkbox on the cluster properties but if he disables it or if he just avoid deploying any Gluster host the result will be pretty the same with just some additional disabled element in the GUI.

By the way engine-setup, if run interactively, already proposes 'Both' as its default. It's just the engine appliance that explicitly override it with 'VirtOnly' just if engine-setup is run in unattended mode.
Comment 6 Yedidyah Bar David 2016-01-13 02:11:20 EST
Another option is to allow passing a custom engine-setup answer file snippet, which will be prepended to the current one, thus override it.
Comment 7 Doron Fediuck 2016-01-13 08:27:17 EST
Gluster installation requires additional work which is not done by default.
The appliance is a standard ovirt installation in a VM, and therefore it uses
the standard ovirt defaults which cannot assume Gluster. As mentioned above,
it can easily be changed / updated during or after installation.
Comment 8 Yedidyah Bar David 2016-01-13 08:48:44 EST
(In reply to Doron Fediuck from comment #7)
> Gluster installation requires additional work which is not done by default.

On the engine side?

> The appliance is a standard ovirt installation in a VM, and therefore it uses
> the standard ovirt defaults which cannot assume Gluster.

The standard ovirt defaults are 'both'. It's the appliance that changes that to 'virt' only.

> As mentioned above,
> it can easily be changed / updated during

Currently, afaiu, only if you give up on automatic run of engine-setup and run it interactively manually.

I understood that at least for hosted-engine, we want to make it so that people that choose to do this automatically using cloud-init will not "suffer".

> or after installation.

Comment 9 Gianluca Cecchi 2016-01-14 06:53:42 EST
Sorry, so this bug remains closed also after comment#8 from Didi? Or do we have any chance to have it reopened and perhaps the default for the appliance to be the same as the interactive setup?
Comment 10 Charlie Inglese 2016-01-14 09:42:36 EST
Is it possible to modify the hosted engine setup to pass in a variable (e.g. OVESETUP_CONFIG/applicationMode=str:<both|virt|gluster>) to cloud-init via modifications to /usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/vm/cloud_init.py? It seems pretty straightforward to add logic to check for a user-defined variable (e.g. applicationMode).

Reference: https://github.com/oVirt/ovirt-hosted-engine-setup/blob/master/src/plugins/ovirt-hosted-engine-setup/vm/cloud_init.py
Lines: 816-821

applicationMode=str:both is the default for the ovirt-engine, so I'd request that the ovirt-engine and appliance remain consistent. Also, it would be nice to be able to set these variables without requiring manual intervention during setup or afterwards.
Comment 11 Fabian Deutsch 2016-01-27 08:00:05 EST
As it's the default in the normal setup flow, I'm fine with also using that inside the oVirt Appliance.
Comment 12 Fabian Deutsch 2016-01-27 08:02:07 EST
Please note that this does not have affect on the use case of the appliance: The supported use-case is only the HE context.
Comment 13 Red Hat Bugzilla Rules Engine 2016-01-27 08:09:13 EST
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.
Comment 14 Fabian Deutsch 2016-02-02 05:10:46 EST
It's been picked up by the nightly builder and is available here:

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