Bug 1076531
| Summary: | vdsm overwrites multipath.conf at every startup if vdsm installed file was replaced | ||
|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Enrico Tagliavini <enrico.tagliavini> |
| Component: | vdsm | Assignee: | Yeela Kaplan <ykaplan> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Elad <ebenahar> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.3 | CC: | abaron, acanan, amureini, bazulay, bugs, enrico.tagliavini, gklein, mgoldboi, nsoffer, oourfali, rbalakri, s.kieske, yeylon, ykaplan |
| Target Milestone: | m1 | ||
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | storage | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
multipath is reconfigured on each vdsm service restart.
Consequence:
multipath.conf should not be changed since important changes done by the sysadmin are needed and might be overwritten.
Fix:
vdsm will fail to start if multipath configuration is required. Multipath will be reconfigured only on user demand using "vdsm-tool configure --module multipath".
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-04 12:59:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1108711 | ||
|
Description
Enrico Tagliavini
2014-03-14 13:52:00 UTC
This is "storage", not "infra". And yes, we should mess with multipath.conf only during installation or via an explicit vdsm-tool command. (In reply to Enrico Tagliavini from comment #0) > Description of problem: > When service vdsm is started multipath.conf is overwritten with a non > working version (for this storage configuration). Vdsm depends on the configuration it provides, we cannot avoid installing our own configuration since on most machines this is the correct configuration. The user configuration is kept by rotating the configuration file. > This happens at every > vdsmd service start, unless the first 2 lines of multipath.conf are: > > # RHEV REVISION 1.0 > # RHEV PRIVATE Exactly, if you replace the configuration with you own file, vdsm will replace it with its own file. But if you edit vdsm generated file with your changes, vdsm will not touch your file. So I think there is no bug here, and this should be closed. We can convert this to RFE, improving the way we configure multipath: 1. Document how the configuration work in the top of the file. The admin should not look in vdsm code to understand how to modify multipath configuration without getting them overwritten by vdsm. 2. Add vdsm specific setting to existing user file instead of overwriting the admin file. Not sure how easy is this. 3. Move the configuration from vdsm startup to vdsm-tool, giving more control to the admin. For example, vdsm can fail with verbose error message if it cannot configure the user file. 4. Vdsm should check current multipath configuration and fail to start if the configuration is not compatible with vdsm. This change is required if we move the configuration to vdsm-tool. Hi Nir, yes as you said 1. is the main problem, I had to look at the python code to sort it out. Adding a comment at the top of the file is very very helpful and very easy to implement I suppose. 2. This is going to be tricky and fragile, and likely not worth the effort anyway, 3. and 4. looks better 3. and 4. this is a good idea. You don't expect a service to change a config file every time it starts up, it is unusual and confusing. Configuring it once automatically when the node is added to the oVirt cluster would be a better idea. A command for the admin can be provided in vdsm-tool if the config file needs to be regenerated. And if I can add my own: 5. What about also improving the autodetection? The anaconda installer did it right, the oVirt config did not. Some code that can be reused maybe? (In reply to Enrico Tagliavini from comment #3) > Hi Nir, > > yes as you said 1. is the main problem, I had to look at the python code to > sort it out. Adding a comment at the top of the file is very very helpful > and very easy to implement I suppose. > > 2. This is going to be tricky and fragile, and likely not worth the effort > anyway, 3. and 4. looks better > > 3. and 4. this is a good idea. You don't expect a service to change a config > file every time it starts up, it is unusual and confusing. Configuring it > once automatically when the node is added to the oVirt cluster would be a > better idea. A command for the admin can be provided in vdsm-tool if the > config file needs to be regenerated. > > And if I can add my own: > > 5. What about also improving the autodetection? The anaconda installer did > it right, the oVirt config did not. Some code that can be reused maybe? I suggest that we discuss this in the mailing list, or if you can describe how it should work, please open a separate bug for this. Returning to NEW - patch was abandonded. Yeela, do you have a different patch for this, as the comment on gerrit suggests? Yeela, can you please provide some doctext for this bug? vdsm doesn't override changes made in multipath.conf after vdsm service restart or a reboot. Verified using 3.6.0-1 vdsm-4.17.0-632.git19a83a2.el7.x86_64 device-mapper-multipath-0.4.9-77.el7.x86_64 oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one. |