Bug 1295945
| Summary: | oVirt appliance defaults to applicationMode=virt | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-appliance | Reporter: | Charlie Inglese <cinglese> |
| Component: | Core | Assignee: | Fabian Deutsch <fdeutsch> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavel Stehlik <pstehlik> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6 | CC: | bugs, dfediuck, didi, fdeutsch, gianluca.cecchi, mgoldboi, sabose, sasundar, s.danzi, stirabos |
| Target Milestone: | ovirt-3.6.3 | Keywords: | Reopened |
| Target Release: | --- | Flags: | dfediuck:
ovirt-3.6.z?
mgoldboi: planning_ack+ fdeutsch: devel_ack+ rule-engine: testing_ack? |
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | node | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-02-02 10:10:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Node | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1258386 | ||
|
Description
Charlie Inglese
2016-01-05 20:57:28 UTC
Simone, do you have any recommendation for this? (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. *** Bug 1295946 has been marked as a duplicate of this bug. *** 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. Another option is to allow passing a custom engine-setup answer file snippet, which will be prepended to the current one, thus override it. 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. (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. How? 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? 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. As it's the default in the normal setup flow, I'm fine with also using that inside the oVirt Appliance. Please note that this does not have affect on the use case of the appliance: The supported use-case is only the HE context. 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. It's been picked up by the nightly builder and is available here: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86_64/ |