curtin

Bug #1735839
Comment #19

Comment 19 for bug 1735839

Revision history for this message

Joshua Powers (powersj) wrote on 2019-01-30:

#19

Dmitrii, Andres,

Ryan has provided some options in #18 in order to resolve this (e.g. a warning message or other usage of other values). Consider the following background:

a) Prior to https://bugs.launchpad.net/bugs/1735839, dname was unstable in the face of users/charms wiping the partition table of devices

b) curtin introduced a change where dname udev rules include WWN or SERIAL values for disks so that users (and charms) can *trust* that if they set a dname it will be present and persistent

c) curtin now raises a RuntimeException when it encounters a device which has requested a dname, but the device does *NOT* include a persistent attribute like a WWN or SERIAL

d) The issue with the new behavior is that for some previous MAAS releases there are KVM nodes which do not contain a serial and these nodes, deployment fails as the storage config
also includes a dname for the disks

Below are three options we see to move this forward:

1) Revert all the changes associated with LP: #1735839, however this is the least desirable outcome; though field may have workaround for this in place already.

2) Log a warning when curtin detects a request for dname on devices that do not have serial. This will allow dnames to continue to be unstable on disks without serial numbers; there is no indication to users or deployments that dname is unstable on certain disks; this seems some
what worse in that we have stated that dnames are now stable, but in some cases they are not and the users have no idea until it fails them.

3) Keep the exception in place and release an SRU to previous MAAS so that new KVM pods have serial numbers, and that existing KVM nodes which are already defined have their guest xml updated to include a serial number such that upon deployment, dname becomes stable.

Curtin’s preference is for (3) so we can establish a guarantee for dname symlinks. That said we are fine with either (1) or (2) as well but would like Field and MAAS to discuss and come to an agreement on what to do and update bug with the decision. Thanks!

Dmitrii, Andres,

Ryan has provided some options in #18 in order to resolve this (e.g. a warning message or other usage of other values).  Consider the following background:

a) Prior to  https://bugs.launchpad.net/bugs/1735839, dname was unstable in the face of users/charms wiping the partition table of devices

b) curtin introduced a change where dname udev rules include WWN or SERIAL values for disks so that users (and charms) can *trust* that if they set a dname it will be present and persistent

c) curtin now raises a RuntimeException when it encounters a device which has requested a dname, but the device does *NOT* include a persistent attribute like a WWN or SERIAL

Below are three options we see to move this forward:

1) Revert all the changes associated with LP: #1735839, however this is the least desirable outcome; though field may have workaround for this in place already.

Curtin’s preference is for (3) so we can establish a guarantee for dname symlinks.  That said we are fine with either (1) or (2) as well but would like Field and MAAS to discuss and come to an agreement on what to do and update bug with the decision. Thanks!