Bug 1070095
| Summary: | MDRaidMember format shows wrong uuid | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jan Safranek <jsafrane> | ||||||||
| Component: | python-blivet | Assignee: | mulhern <amulhern> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 7.0 | CC: | amulhern, jsafrane, pkotvan | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | python-blivet-0.61.0.1-1 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2015-03-05 14:05:47 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Jan Safranek
2014-02-26 08:59:28 UTC
I'll take this one, I've bee looking at this info recently. bz#1041462 is related because it is also about getting the array, not the member, by means of the mdUuid. It seems like mdUuid can be set in two ways:
by calling udev_device_get_md_uuid on info obtained by reading uevent files
by setting it from the uuid of an MDRaidArrayDevice.
So if in this instance we see its mdadmin form that means it was probably
setting it in the second way.
Also, it looks like UUIDs have a standard format:
UUID = time-low "-" time-mid "-"
time-high-and-version "-"
clock-seq-and-reserved
clock-seq-low "-" node
time-low = 4hexOctet
time-mid = 2hexOctet
time-high-and-version = 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low = hexOctet
node = 6hexOctet
hexOctet = hexDigit hexDigit
hexDigit =
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
which I got here: http://tools.ietf.org/html/rfc4122.
So udev has the canonical form and mdadmin doesn't but its been doing that for a long time, so we should probably just cope by canonicalizing information from
mdadmin while perhaps using the python UUID class rather than str to hold this info.
The nice thing is that if you give the UUID constructor an mdadm type string, with '-' substituted for ':', it will automatically redistribute the dashes, as:
>>> uuid.UUID('8d613527-31f80556-9890df07-0e937c77')
UUID('8d613527-31f8-0556-9890-df070e937c77')
Easy then to check equality of UUIDs.
- mulhern
Created attachment 901815 [details]
A patch corresponding to a change that already exists in master
The fix is desirable but went in with commit 143c75ae70a0164946a2987409beae2c0afd4547 in master, which also includes a lot of stuff not appropriate for RHEL7.
Posted a patch set to address this problem on master. The whole situation is actually made more difficult by the fact that libudev can succesfully extract a good deal of MD_* key/value pairs. So, it is not reasonable to assume the mdexamine is the only thing that will populate the udev dict. Created attachment 913921 [details]
Screenshot showing udev's ability to get MD_ values
Posted again. Note that the suggested solution, using MD_DEV_UUID will only work if the metadata version is greater than 0.9. But preliminary tests seem to indicate that it works just fine there. Jan, if you have any further suggestions about how to get the correct UUID for the device, let me know. Posted a fourth version of the patch set for master, might be the last. Pushed to master. dlehman is working on some further patches for master that may effect this, so I want to hold off pushing any of this for a bit. Created attachment 969046 [details] reproducer helper script Steps to reproduce (for QA): 1) create a MD RAID array (any, I use level 1 with two devices): $ mdadm -C -l 1 -n 2 /dev/md/test /dev/vdb{1,2} 2) run attached script in a python shell (ipython strongly recommended, it has tab completion) and do not finish the shell (that's what -i does): $ python -i blivet_init.py (or $ ipython -i blivet_init.py) The script just initializes blivet in local variable 'b', it does not reproduce the bug! Keep the script around, it's very helpful and very powerful with ipython's tab completion. 3) examine blivet's view of MD RAID (in the python/ipython console): >>> raid = b.mdarrays[0] >>> member = raid.parents[0] >>> print member.format.uuid b0d583cd-2bac-d69c-bd41-649efaedfce8 >>> print member.format.mdUuid 9ca0be31-5740-eb24-bdcb-ea66a4602267 (that's correct output, i.e. with the bug fixed, tested on Fedora 21) Creating fully automated reproducer should be a quick exercise now. 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. https://rhn.redhat.com/errata/RHBA-2015-0313.html |