| 2017-12-01 21:09:01 |
Dmitrii Shcherbakov |
bug |
|
|
added bug |
| 2017-12-01 21:09:13 |
Dmitrii Shcherbakov |
bug task added |
|
maas |
|
| 2017-12-01 21:15:16 |
Dmitrii Shcherbakov |
description |
Block devices can be identified by a GPT placed on them.
Each partition table contains a UUID which uniquely identifies a device.
sudo blkid -o udev -p /dev/nvme0n1
ID_PART_TABLE_UUID=8c5e98a4-0d1e-40ae-8f43-80544a2c204b
ID_PART_TABLE_TYPE=gpt
gdisk:
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-0D1E-40AE-8F43-80544A2C204B
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table.
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/by-gpt-uuid/<uuid> |
Block devices can be identified by a GPT placed on them.
Each partition table contains a UUID which uniquely identifies a device.
sudo blkid -o udev -p /dev/nvme0n1
ID_PART_TABLE_UUID=8c5e98a4-0d1e-40ae-8f43-80544a2c204b
ID_PART_TABLE_TYPE=gpt
gdisk:
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-0D1E-40AE-8F43-80544A2C204B
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table. This may help us workaround this: pad.lv/1604501
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/by-gpt-uuid/<uuid> |
|
| 2017-12-01 21:20:36 |
Ryan Harper |
curtin: importance |
Undecided |
Wishlist |
|
| 2017-12-01 21:20:36 |
Ryan Harper |
curtin: status |
New |
Triaged |
|
| 2017-12-07 08:48:10 |
Lee Trager |
maas: status |
New |
Triaged |
|
| 2017-12-07 08:48:14 |
Lee Trager |
maas: importance |
Undecided |
Wishlist |
|
| 2017-12-07 08:49:08 |
Lee Trager |
maas: milestone |
|
2.4.x |
|
| 2018-07-23 09:21:15 |
Dmitrii Shcherbakov |
summary |
feature request: /dev/by-dname symlinks based on GUID patition table UUIDs |
feature request: /dev/by-dname symlinks based on wwn/wwid |
|
| 2018-07-23 10:22:01 |
Dmitrii Shcherbakov |
summary |
feature request: /dev/by-dname symlinks based on wwn/wwid |
/dev/by-dname symlinks based on wwn/wwid |
|
| 2018-07-23 10:31:59 |
Dmitrii Shcherbakov |
bug |
|
|
added subscriber Ante Karamatić |
| 2018-07-23 10:32:07 |
Dmitrii Shcherbakov |
bug |
|
|
added subscriber Canonical Field Critical |
| 2018-07-23 10:35:43 |
Dmitrii Shcherbakov |
description |
Block devices can be identified by a GPT placed on them.
Each partition table contains a UUID which uniquely identifies a device.
sudo blkid -o udev -p /dev/nvme0n1
ID_PART_TABLE_UUID=8c5e98a4-0d1e-40ae-8f43-80544a2c204b
ID_PART_TABLE_TYPE=gpt
gdisk:
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-0D1E-40AE-8F43-80544A2C204B
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table. This may help us workaround this: pad.lv/1604501
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/by-gpt-uuid/<uuid> |
Currently /dev/disk/by-dname symlinks are not created if a device does not have a partition table or a super block.
There needs to be a way to create auto-create by-dname symlinks based on unique wwn/eui identifiers and symlinks via udev rules installed during the deployment stage.
Old description:
Block devices can be identified by a GPT placed on them.
Each partition table contains a UUID which uniquely identifies a device.
sudo blkid -o udev -p /dev/nvme0n1
ID_PART_TABLE_UUID=8c5e98a4-0d1e-40ae-8f43-80544a2c204b
ID_PART_TABLE_TYPE=gpt
gdisk:
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-0D1E-40AE-8F43-80544A2C204B
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table. This may help us workaround this: pad.lv/1604501
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/by-gpt-uuid/<uuid> |
|
| 2018-07-24 08:01:22 |
Dmitrii Shcherbakov |
bug |
|
|
added subscriber Canonical Field High |
| 2018-07-24 08:01:34 |
Dmitrii Shcherbakov |
removed subscriber Canonical Field Critical |
|
|
|
| 2018-07-25 09:37:45 |
Yoshi Kadokawa |
bug |
|
|
added subscriber Yoshi Kadokawa |
| 2018-08-06 14:25:52 |
Andres Rodriguez |
maas: status |
Triaged |
Invalid |
|
| 2018-08-06 14:25:56 |
Andres Rodriguez |
maas: importance |
Wishlist |
Undecided |
|
| 2018-08-06 14:25:58 |
Andres Rodriguez |
maas: milestone |
2.4.x |
|
|
| 2018-10-31 18:53:34 |
Ryan Harper |
merge proposal linked |
|
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/358116 |
|
| 2018-10-31 18:53:44 |
Ryan Harper |
curtin: importance |
Wishlist |
High |
|
| 2018-10-31 18:53:50 |
Ryan Harper |
curtin: status |
Triaged |
In Progress |
|
| 2018-11-29 16:47:03 |
Server Team CI bot |
curtin: status |
In Progress |
Fix Committed |
|
| 2018-12-06 18:13:42 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/360217 |
|
| 2018-12-07 16:28:32 |
Ryan Harper |
curtin: status |
Fix Committed |
Fix Released |
|
| 2018-12-08 14:43:03 |
Dmitrii Shcherbakov |
curtin: status |
Fix Released |
New |
|
| 2019-01-17 15:32:11 |
Ryan Harper |
curtin: status |
New |
Incomplete |
|
| 2019-02-05 19:35:45 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/362752 |
|
| 2019-02-08 21:12:24 |
Server Team CI bot |
curtin: status |
Incomplete |
Fix Committed |
|
| 2019-02-21 14:09:26 |
Tori Hegarty |
bug |
|
|
added subscriber Tori |
| 2019-02-26 14:31:36 |
Dmitrii Shcherbakov |
attachment added |
|
vhost6-dumpxml-26-02-2019.xml https://bugs.launchpad.net/curtin/+bug/1735839/+attachment/5241790/+files/vhost6-dumpxml-26-02-2019.xml |
|
| 2019-05-08 17:15:55 |
Dmitrii Shcherbakov |
curtin: status |
Fix Committed |
Fix Released |
|
