[enhancement] partition tagging is not supported

[Dmitrii Shcherbakov]

Tagging a block device is possible, tagging a partition is not.

juju storage allows one to create storage pools based on tags.

A usage example would be:

juju create-storage-pool osd-devices maas tags=data

and then somewhere in a charm:

storage-get -s <storage-id> <attribute>
storage-get -s data/0 location

# would return something like /dev/sdb1

The lack of partition tagging doesn't allow one to utilize partitions with juju storage.

ubuntu@maas:~$ maas maas version read
Success.
Machine-readable output follows:
{"version": "2.3.0~alpha1", "capabilities": ["networks-management", "static-ipaddresses", "ipv6-deployment-ubuntu", "devices-management", "storage-deployment-ubuntu", "network-deployment-ubuntu", "bridging-interface-ubuntu", "bridging-automatic-ubuntu", "authenticate-api"], "subversion": "6165-geae082b-0ubuntu1~16.04.1"}

http://paste.ubuntu.com/25396799/

ubuntu@maas:~$ maas maas block-device add-tag rw7fq3 53 tag=part-tag
Not Found

ubuntu@maas:~$ maas maas block-device add-tag rw7fq3 42 tag=part-tag
Success.
Machine-readable output follows:
{
    "available_size": 38713425920,
    "name": "sdb",
    "id": 42,
    "used_for": "GPT partitioned with 1 partition",
    "tags": [
        "rotary",
        "data",
        "part-tag"
    ],
    "path": "/dev/disk/by-dname/sdb",
    "model": "QEMU HARDDISK",
    "partition_table_type": "GPT",
    "system_id": "rw7fq3",
    "type": "physical",
    "filesystem": null,
    "size": 68719476736,
    "resource_uri": "/MAAS/api/2.0/nodes/rw7fq3/blockdevices/42/",
    "serial": "drive-scsi0-0-0-3",
    "block_size": 4096,
    "used_size": 30002905088,
    "partitions": [
        {
            "bootable": false,
            "resource_uri": "/MAAS/api/2.0/nodes/rw7fq3/blockdevices/42/partition/53",
            "device_id": 42,
            "path": "/dev/disk/by-dname/sdb-part1",
            "system_id": "rw7fq3",
            "size": 29997662208,
            "id": 53,
            "used_for": "Unused",
            "type": "partition",
            "filesystem": null,
            "uuid": "b5739ebc-bb03-44ea-8f67-79e9d3ad643d"
        }
    ],
    "id_path": "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-3",
    "uuid": null
}

[Andres Rodriguez (andreserl)]

Hi Dmitrii,

For partition tagging, I just want to clarify something:

1. Would you want to add any tag, or would you want maas to add a prefix/suffix for the tag. e.g. you adding the tag 'blah' on part1, would you expect the tag to be 'blah-part1' ?

2. Would you be expected to add a tag to a partition that's the same for a block-device ? e.g. sda -> nvme , sdb-part1 -> nvme?

3. If (2) is true, how would you expect to differentiate between a partition and a block device when requesting a machine ?

[Andres Rodriguez (andreserl)]

Blake came out with a good solution, where MAAS would add pseudo/inherited tag based on whether it is a partition or a block device. So all of this would work:

storage=root:(nvme) # would return whatever it finds first
storage=root:(partition, nvme) # would return partitions tagged nvme
storage=root:(blockdev, nvme) # would return block devices tagged nvme.

[Dmitrii Shcherbakov (dmitriis)]

re #2:

1. Yes, we have one use-case right now for a device used for multiple purposes which requires custom partition tags, in other words, I would expect "blah" to be applied to a partition, not 'blah-part1'.

For an NVMe device:

p1 - cache device (partition) for bcache0
p2 - cache device (partition) for bcache1
p3 - partition device for ceph journal or ceph (wal & db)

So, I would expect:

# all block devices (bcache in our case) tagged as osd-data for ceph osd (works)
juju create-storage-pool osd-devices maas tags=osd-data
# a tag for bcache1 device (works) - used for node-local VM storage
juju create-storage-pool ephemeral maas tags=bcache-ephemeral
# a tag for a journal partition
juju create-storage-pool nvme-journal maas tags=journal,nvme

2. I suppose it would be useful. If a device is partitioned there seems to be no point in adding tags other than ones providing device type information to the partition such as "nvme" and doing that by hand is cumbersome;

3. I guess the approach from comment #3 would solve it.

The most specific request would be:

juju create-storage-pool nvme-journal maas tags=journal,nvme,partition

[Blake Rouse (blake-rouse)]

Working on this now and some things have to be changed with how the constraints will work with a partition.

The "partition" tag will always be required when a match for a partition needs to occur, otherwise MAAS will always match on a block devices that has no partitions or a filesystem. This is to reserve comparability and not break the allocation API.

Just to use the comment #3 as an example:

storage=root:(nvme) # would return block device with nvme
storage=root:(partition, nvme) # would return partitions tagged nvme
storage=root:(blockdev, nvme) # 'blockdev' will no longer be a tag flag. So would return block device with tag blockdev and nvme.

[Dmitrii Shcherbakov (dmitriis)]

It seems reasonable that there should be a separate tag in the query.

Will there be any way though to do a combined query with one API call? For example, a DB application might want to use some storage tagged with "nvme" and "db" (partition or not). Automation providing nodes and devices via MAAS would then have to do the following for each node:

1) find all devices tagged as "nvme" and "db";
2) if there are no partitions on those, add those to the list of devices to use;
2) find all devices tagged as "nvme" with partitions and match any partition with the "db" tag.

The result (after by-id symlink resolution) could be something like: [/dev/nvme0n1p2, /dev/nvme1n1]

[Blake Rouse (blake-rouse)]

No it will not fallback to searching for a partition, when a block device cannot be found to match that tag, but a partition does exist. That would create undetermined behavior to the charm and the deployer of the charm.

If you want to attach to a partition you have to be explicit otherwise it matches to a block device.

[Andres Rodriguez (andreserl)]

I've added the Juju project to this bug because in order to support requesting for a partition (via tag, and similarly to how we do it for block devices), Juju would need to be changed to correctly interpret this request.

[Blake Rouse (blake-rouse)]

This pull request for gomaasapi adds the support for handling partitions in the allocation constraint map response.

https://github.com/juju/gomaasapi/pull/75

[Anastasia (anastasia-macmood)]

PR against 2.3: https://github.com/juju/juju/pull/9235