Bug 1043524
| Summary: | Restart libvirtd every deploy | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-host-deploy | Reporter: | Alon Bar-Lev <alonbl> |
| Component: | Plugins.VDSM | Assignee: | Alon Bar-Lev <alonbl> |
| Status: | CLOSED ERRATA | QA Contact: | Tareq Alayan <talayan> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.1.0 | CC: | acathrow, bazulay, bugs, dougsland, iheim, istein, pstehlik, Rhev-m-bugs, sherold, ybronhei, yeylon |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | 1.1.3 | Flags: | pm-rhel:
blocker+
alonbl: devel_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | infra | ||
| Fixed In Version: | is28 | Doc Type: | Enhancement |
| Doc Text: |
libvirtd is now restarted after each host-deploy process, in order to pick up VDSM and pki configuration changes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-21 15:57:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1049022 | ||
|
Description
Alon Bar-Lev
2013-12-16 14:42:19 UTC
Barak, Do you see potential issue in doing so? Thanks, what reports? can you be more specific? In ovirt-3.3 we changed the code to restart libvirt after each successful configure, and in master we should handle it right unless there is an issue that i'm not familiar with (In reply to Yaniv Bronhaim from comment #2) > what reports? can you be more specific? In ovirt-3.3 we changed the code to > restart libvirt after each successful configure, and in master we should > handle it right unless there is an issue that i'm not familiar with The pki configuration was not applied in all cases, as the recent vdsm considered it already configured. the ca,cert and key files? is this being set again by the host-deploy or only by libvirt configure with the defaults? if host deploy overwrites the defaults it must restart libvirt manually (isconfigured shouldn't recognize it), but if its the defaults configure, libvirt service should be restarted after the configure unless there is a bug (In reply to Yaniv Bronhaim from comment #4) > the ca,cert and key files? is this being set again by the host-deploy or > only by libvirt configure with the defaults? if host deploy overwrites the > defaults it must restart libvirt manually (isconfigured shouldn't recognize > it), but if its the defaults configure, libvirt service should be restarted > after the configure unless there is a bug Once again... the --force should have handled anything... now that you removed this we need to take care of it at host-deploy. The opened question in this bug is simple: what are the implications [if any]. verified on ovirt-host-deploy-1.1.3-1.el6ev.noarch
from log:
========
2013-12-29 17:37:30 DEBUG otopi.context context._executeMethod:123 Stage closeup METHOD otopi.plugins.ovirt_host_deploy.vdsm.packages.Plugin._start
2013-12-29 17:37:30 INFO otopi.plugins.ovirt_host_deploy.vdsm.packages packages._start:173 Stopping libvirtd
2013-12-29 17:37:30 DEBUG otopi.plugins.otopi.services.rhel rhel.exists:121 check if service libvirtd exists
2013-12-29 17:37:30 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:366 execute: ('/sbin/initctl', 'status', 'libvirtd'), executable='None', cwd='None', env=None
2013-12-29 17:37:30 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:383 execute-result: ('/sbin/initctl', 'status', 'libvirtd'), rc=0
2013-12-29 17:37:30 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:441 execute-output: ('/sbin/initctl', 'status', 'libvirtd') stdout:
libvirtd start/running, process 2323
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0074.html |