olivierlambert commented on issue #13292:
URL: https://github.com/apache/cloudstack/issues/13292#issuecomment-5820646083
@DaanHoogland here's the mapping, checked against the sm currently shipped
in XCP-ng 8.3 (`sm-3.2.12-23.5`).
The short version: `lvhdutil` wasn't just renamed. The same refactor
(preparing QCOW2 support) also turned `vhdutil` from a set of module-level
functions into a class. So guarding the import alone (#13692) isn't enough:
once the import error is gone, the next call to `vhdutil.getParent()` fails
with `AttributeError`, **including on the NFS path**.
### Symbol mapping
| Old (sm ≤ 3.2.12-17.x) | XCP-ng 8.3 current |
|---|---|
| `lvhdutil.VG_PREFIX`, `lvhdutil.VG_LOCATION` | `constants.VG_PREFIX`,
`constants.VG_LOCATION` |
| `lvhdutil.extractUuid` | `lvmcowutil.LvmCowUtil.extractUuid`
(staticmethod, same behaviour) |
| `vhdutil.getVHDInfoLVM(lvName, extractFn, vgName)` |
`vhdutil.VhdUtil().getInfoFromLVM(lvName, extractFn, vgName)`. The returned
object still has `.parentUuid` |
| `vhdutil.getParent(path, extractFn)` | `vhdutil.VhdUtil().getParent(path,
extractFn)` |
| `vhdutil.getSizePhys(path)` | `vhdutil.VhdUtil().getSizePhys(path)` |
| `vhdutil.setHidden(path, hidden)` | `vhdutil.VhdUtil().setHidden(path,
hidden)` |
| `vhdutil.LOCK_TYPE_SR` | `lock.LOCK_TYPE_SR` |
| `cleanup.FileVDI.extractUuid` | unchanged |
### Affected CloudStack files (installed on 8.3 via `xcpserver83/patch`)
- `xenserver84/cloud-plugin-storage`: `getPrimarySRPath()`, `scanParent()`,
`getParent()`. The NFS branch (`vhdutil.getParent(path,
cleanup.FileVDI.extractUuid)`) is also broken.
- `xenserver84/vmopsSnapshot`: same calls, plus `vhdutil.getSizePhys()` and
`vhdutil.setHidden()`. #13692 doesn't touch this file.
- `xcpserver83/NFSSR.py`: `vhdutil.LOCK_TYPE_SR` (the traceback
@AlexanderKgr posted above). More on this below.
If you need one code base that works with both old and new sm, a small
compatibility shim at the top of each plugin should do it:
```python
try:
# XCP-ng 8.3 with refactored sm
from constants import VG_PREFIX, VG_LOCATION
from lvmcowutil import LvmCowUtil
from vhdutil import VhdUtil
_vhdutil = VhdUtil()
lvm_extract_uuid = LvmCowUtil.extractUuid
vhd_get_parent = _vhdutil.getParent
vhd_get_info_lvm = _vhdutil.getInfoFromLVM
vhd_get_size_phys = _vhdutil.getSizePhys
vhd_set_hidden = _vhdutil.setHidden
except ImportError:
# older sm
import lvhdutil
import vhdutil
VG_PREFIX, VG_LOCATION = lvhdutil.VG_PREFIX, lvhdutil.VG_LOCATION
lvm_extract_uuid = lvhdutil.extractUuid
vhd_get_parent = vhdutil.getParent
vhd_get_info_lvm = vhdutil.getVHDInfoLVM
vhd_get_size_phys = vhdutil.getSizePhys
vhd_set_hidden = vhdutil.setHidden
```
Then replace the call sites: `vhdutil.getParent(...)` becomes
`vhd_get_parent(...)`, `lvhdutil.extractUuid` becomes `lvm_extract_uuid`, and
so on.
Side note: on LVM-based SRs, volumes can now be `QCOW2-<uuid>` as well as
`VHD-<uuid>`. `getVHD()` hard-codes the `VHD-` prefix. That's fine today, since
CloudStack only creates VHDs, but it will matter if QCOW2 support comes up.
### The bigger issue: `NFSSR.py` override
`xcpserver83/patch` replaces the host's `/opt/xensource/sm/NFSSR.py` with
CloudStack's own copy. That copy is a much older fork of the driver: it's based
on `FileSR.FileSR` instead of `SharedFileSR`, and it has no CBT and no NFS
version handling. Any sm update can break it, as happened here.
From what I can see, the only reason for the fork is to mount `serverpath`
directly instead of `serverpath/<sr-uuid>`. The stock driver has supported that
for years through `sm-config:nosubdir=true` (set at SR creation, or with `xe
sr-param-set uuid=<sr> sm-config:nosubdir=true` on existing SRs). Could
CloudStack drop the NFSSR override for 8.3 and pass `nosubdir=true` instead?
That would remove a whole class of breakage like this one, and CloudStack NFS
SRs would get the current driver.
We're happy to review a PR and to test it against our `testing` repo before
the next sm update lands.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
