Comment 22 for bug 1735839

> Is this acceptable? Won't users file that as a bug?

I suspect that either there is a very small amount of users or no users at all that depend on dname symlinks in VMs. Based on field engineering experience there are none because if VMs are created with a single block device (where root fs resides), file system paths are typically used in automation, not dname symlinks. None of our current bundles rely on by-dname symlinks with pod VMs.

I don't like to use ad-hoc statistics to reason about behavioral changes but it is what it is considering the situation.

> That may be acceptable if we have a MAAS version released where dnames are stable (and enforced, though the question remains where to enforce this; in curtin or MAAS)?

We cannot enforce that in every case, e.g. when I use virsh provider + my own domain XML without serial/wwid specified for block devices, I don't expect MAAS to parse domain XML and tell me there is something missing.

However, I would warn a user via MAAS based on outputs of 00-maas-07-block-devices commissioning script: e.g. if '"SERIAL": "drive-scsi0-0-0-0"' is present, it is clearly not a persistent ID, and a user should be told that it cannot be relied on for persistent device symlinks.

Likewise, if there is a physical device with a damaged EEPROM or otherwise inaccessible Vital Product Data (VPD), in which case serial/wwid wouldn't be accessible, MAAS should tell the user about that.

To summarize: it's better to warn explicitly than fail commissioning.