Created attachment 1279971 [details] ovirt-hosted-engine-setup Description of problem: [HE] deploy of ovirt-engine-appliance-4.2 Failed to enable service 'openvswitch' Version-Release number of selected component (if applicable): ovirt-engine-appliance-4.2-20170517.1.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1. Deploy the ovirt appliance by run: "hosted-engine --deploy --config-append=/etc/ansible-ovirt/answers" Actual results: The deploy failed with the following error: [ ERROR ] Failed to execute stage 'Misc configuration': Failed to enable service 'openvswitch'(see attached logs). Expected results: To handle the openvswitch as part of the appliance installation process. Additional info: I talked with Simone about it and he said that ovn stuff is not a direct dependency of engine-setup so it's not there, when we create the appliance. but the engine-setup is now looking for it.
Created attachment 1279972 [details] ovirt-engine-setup
openvswitch (and other OVN dependencies) are not in the appliance although engine-setup try to enable it by default. 2017-05-18 12:41:40,276+0300 DEBUG otopi.context context._executeMethod:128 Stage misc METHOD otopi.plugins.ovirt_engine_setup.ovirt_engine.network.ovirtproviderovn.Plugin._restart_ovn_services 2017-05-18 12:41:40,276+0300 DEBUG otopi.plugins.otopi.services.systemd systemd.startup:99 set service openvswitch startup to True 2017-05-18 12:41:40,276+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'show', '-p', 'Id', 'openvswitch.service'), executable='None', cwd='None', env=None 2017-05-18 12:41:40,286+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'show', '-p', 'Id', 'openvswitch.service'), rc=0 2017-05-18 12:41:40,286+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'show', '-p', 'Id', 'openvswitch.service') stdout: Id=openvswitch.service 2017-05-18 12:41:40,287+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'show', '-p', 'Id', 'openvswitch.service') stderr: 2017-05-18 12:41:40,287+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'enable', u'openvswitch.service'), executable='None', cwd='None', env=None 2017-05-18 12:41:40,295+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'enable', u'openvswitch.service'), rc=1 2017-05-18 12:41:40,295+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'enable', u'openvswitch.service') stdout: 2017-05-18 12:41:40,295+0300 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'enable', u'openvswitch.service') stderr: Failed to execute operation: No such file or directory
Yaniv, Moran, we discussed about this over devel mailing list at http://lists.ovirt.org/pipermail/devel/2017-May/030420.html without a final decision. Is openvswitch to be considered optional (so default=no in engine-setup) or a main feature (so it has to be an engine dependency as dwh)?
(In reply to Sandro Bonazzola from comment #3) > Yaniv, Moran, we discussed about this over devel mailing list at > http://lists.ovirt.org/pipermail/devel/2017-May/030420.html without a final > decision. > Is openvswitch to be considered optional (so default=no in engine-setup) or > a main feature (so it has to be an engine dependency as dwh)? there's a third option, which I prefer: openvswitch is still optional, but defaults to true. A user can opt out and not configure OVN, but most users should not.
(In reply to Dan Kenigsberg from comment #4) > there's a third option, which I prefer: openvswitch is still optional, but > defaults to true. A user can opt out and not configure OVN, but most users > should not. Please clarify. Based on previous discussions, I understand that what you mean is: 1. It defaults to True in normal run of engine-setup, and is not a direct dependency of the engine. So if a user installs only 'ovirt-engine', engine-setup will then install ovs if the user accepted the default True. 2. It defaults to False in the answer file supplied on the appliance, so running engine-setup there with the supplied file will not install/configure ovs. This will indeed solve all problems, including current bug, but as I said in private, I am not sure it makes sense to me. I do not see the appliance as a special kind of installation - imo the defaults in it should be identical to normal run except for very specific reasons. Do we have such a reason for ovs?
(In reply to Yedidyah Bar David from comment #5) > 1. It defaults to True in normal run of engine-setup, and is not a direct > dependency of the engine. So if a user installs only 'ovirt-engine', > engine-setup will then install ovs if the user accepted the default True. From hosted-engine-setup we are going to run engine-setup in offline mode and so it will not work there.
(In reply to Sandro Bonazzola from comment #3) > Yaniv, Moran, we discussed about this over devel mailing list at > http://lists.ovirt.org/pipermail/devel/2017-May/030420.html without a final > decision. > Is openvswitch to be considered optional (so default=no in engine-setup) or > a main feature (so it has to be an engine dependency as dwh)? I would guess most users would want this enabled. I suggest to have it installed with appliance like other optional components unless the impact of appliance size it considerable.
Verified with: rhvm-appliance-4.2-20171207.0.el7.noarch Hosted engine successfully deployed.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.