Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add per OSD crush_device_class definition #49555

Merged
merged 1 commit into from Feb 13, 2023
Merged

Conversation

fmount
Copy link
Contributor

@fmount fmount commented Dec 23, 2022

This patch introduces a per osd crush_device_class definition in the DriveGroup spec. The Device object is extended to support a crush_device_class parameter which is processed by ceph-volume when drives are prepared in batch mode. According to the per osd defined crush device classes, drives are collected and grouped in a dict that is used to produce a set of ceph-volume commands that eventually apply (if defined) the right device class. The test_drive_group unit tests are also extended to make sure we're not breaking compatibility with the default definition and the new syntax is validated, raising an exception if it's violated.

Fixes: https://tracker.ceph.com/issues/58184

Signed-off-by: Francesco Pantano fpantano@redhat.com

Contribution Guidelines

Checklist

  • Tracker (select at least one)

    • References tracker ticket
    • Very recent bug; references commit where it was introduced
    • New feature (ticket optional)
    • Doc update (no ticket needed)
    • Code cleanup (no ticket needed)
  • Tests (select at least one)

Show available Jenkins commands
  • jenkins retest this please
  • jenkins test classic perf
  • jenkins test crimson perf
  • jenkins test signed
  • jenkins test make check
  • jenkins test make check arm64
  • jenkins test submodules
  • jenkins test dashboard
  • jenkins test dashboard cephadm
  • jenkins test api
  • jenkins test docs
  • jenkins render docs
  • jenkins test ceph-volume all
  • jenkins test ceph-volume tox
  • jenkins test windows

@fmount
Copy link
Contributor Author

fmount commented Dec 23, 2022

@adk3798 can you check this when you have the chance? It's something we already discussed at the orch meeting and it basically solves the tracker in $subject.
With this change you can either have the form:

service_type: osd
service_id: testing_drivegroup
placement:
  host_pattern: hostname
data_devices:
  paths:
  - /dev/sda
  - /dev/sdb

or specify a per disk crush_device_class like the following:

service_type: osd
service_id: testing_drivegroup
placement:
  host_pattern: hostname
crush_device_class: hdd
data_devices:
  paths:
  - data: /dev/sda
    crush_device_class: ssd
  - data: /dev/sdb
    crush_device_class: hdd
  - data: /dev/sdc
    crush_device_class: nvme
  - data: /dev/sdd

If no crush_device_class is defined within paths, the OSD can use the global one (the value present in the spec), and be collected in the right dict entry.
If nothing is specified (neither within the paths spec nor at global level, then ceph-volume won't append any --crush-device-class to the command.
A few examples that cover the combinations we have can be found here [1].

[1] https://paste.opendev.org/show/bEZJEMD67J1i1oPFj5mf/

@fmount
Copy link
Contributor Author

fmount commented Dec 23, 2022

@adk3798 I suspect the failing tests [1] are unrelated to this patch, right?

[1] https://jenkins.ceph.com/job/ceph-pull-requests/108756/console

- data: /dev/sdb
- crush_device_class: ssd
- data: /dev/sdc
- crush_device_class: nvme
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the right YAML structure? I expected something more like:

   data_devices:
        paths:
        - data: /dev/sdb
             crush_device_class: ssd
        - data: /dev/sdc
            crush_device_class: nvme

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I had an issue in the previous change. The right structure is the following:

    ...
    ...
    spec:
      data_devices:
        paths:
        - data: /dev/sdb
          crush_device_class: ssd
        - data: /dev/sdc
          crush_device_class: nvme
      db_devices:
         ... 

where paths is translated into a json like paths: [ { "data": "/dev/sdb", "crush_device_class": "ssd" }, { "data": "/dev/sdc", "crush_device_class": "nvme" } ] which is easy to process (and validate) from cephadm.
Thanks, nice catch on that issue I had with the yaml definition, just updated the doc change!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YAML! I hate YAML! Even with strawberries!
;)

Copy link
Contributor

@anthonyeleven anthonyeleven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs LGTM, no code or overall PR approval should be inferred.

@adk3798
Copy link
Contributor

adk3798 commented Jan 5, 2023

@adk3798 I suspect the failing tests [1] are unrelated to this patch, right?

[1] https://jenkins.ceph.com/job/ceph-pull-requests/108756/console

they look unrelated, yeah

@adk3798
Copy link
Contributor

adk3798 commented Jan 5, 2023

jenkins retest this please

Copy link
Contributor

@adk3798 adk3798 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM, some minor things/cleanup

src/python-common/ceph/deployment/drive_group.py Outdated Show resolved Hide resolved
src/python-common/ceph/deployment/translate.py Outdated Show resolved Hide resolved
src/python-common/ceph/deployment/translate.py Outdated Show resolved Hide resolved
src/python-common/ceph/deployment/drive_group.py Outdated Show resolved Hide resolved
dg = DriveGroupSpec.from_json(yaml.safe_load(test_input))
assert dg.service_id == 'testing_drivegroup'
assert all([isinstance(x, Device) for x in dg.data_devices.paths])
assert dg.data_devices.paths[0].path == '/dev/sda'
if isinstance(dg.data_devices.paths[0].path, str):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was mypy complaining without this extra isinstance? It seems like the path attribute for the Device class is still just type str so it feels like this shouldn't be necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this change just solved that problem. I'll add a stacktrace to show you the issue, but definitely having this check (that doesn't change the nature of the test) helped to make it happy

@fmount fmount force-pushed the drive_group_crush branch 2 times, most recently from 07f59ca to be8f4bc Compare January 19, 2023 12:44

# For this use case we don't apply any custom crush_device_classes
# Note that filestore is not supported anymore by the DriveGroupSpec
if self.spec.objectstore == 'filestore':
Copy link
Contributor Author

@fmount fmount Jan 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adk3798 I'm not sure we want to keep L121-L138 (the filestore use case). This code is actually never reached, and if filestore is added to the spec:

test_input11 = """service_type: osd
service_id: testing_drivegroup
placement:
  host_pattern: hostname
objectstore: filestore
data_devices:
  paths:
  - path: /dev/ceph_vg/ceph_lv_data
    crush_device_class: ssd
  - path: /dev/ceph_vg1/ceph_lv_data1
  - path: /dev/ceph_vg1/ceph_lv_data2
  - path: /dev/ceph_vg1/ceph_lv_data3
  - path: /dev/ceph_vg1/ceph_lv_data4
"""

the spec validation will fail with the following error:

    raise DriveGroupValidationError(self.service_id,
ceph.deployment.drive_group.DriveGroupValidationError: Failed to validate OSD spec "testing_drivegroup": filestore is not supported. Must be one of ('bluestore')

which is actually expected from [1].
We can leave this block here (and it's out of the for loop), but it's just something we want to clean up (maybe in a follow up change?)

[1] https://github.com/ceph/ceph/blob/main/src/python-common/ceph/deployment/drive_group.py#L328-L331

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have to check if this is getting used by anything else somehow that could make use of that. Maybe something for a follow up PR, yeah

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, filestore is going to be deprecated and removed soon

@fmount fmount requested a review from adk3798 January 19, 2023 12:58
- path: /dev/sdb
crush_device_class: hdd
- path: /dev/sdc
crush_device_class: ssd
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that test_input6 != test_input5 as here we have multiple device classes

This patch introduces a per osd crush_device_class definition in the
DriveGroup spec. The Device object is extended to support a
crush_device_class parameter which is processed by ceph-volume when
drives are prepared in batch mode. According to the per osd defined
crush device classes, drives are collected and grouped in a dict that is
used to produce a set of ceph-volume commands that eventually apply (if
defined) the right device class. The test_drive_group unit tests are
also extended to make sure we're not breaking compatibility with the
default definition and the new syntax is validated, raising an exception
if it's violated.

Fixes: https://tracker.ceph.com/issues/58184

Signed-off-by: Francesco Pantano <fpantano@redhat.com>
Copy link
Contributor

@adk3798 adk3798 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@adk3798
Copy link
Contributor

adk3798 commented Jan 22, 2023

https://pulpito.ceph.com/adking-2023-01-21_05:38:21-orch:cephadm-wip-adk-testing-2023-01-20-1359-distro-default-smithi/

Lots of failures (13) but all accounted for

Overall, PRs in the run should be okay to merge other than the mon crush location one causing failures. Will start to try and clean up the test suite now that we're able to make builds and run tests again.

@adk3798
Copy link
Contributor

adk3798 commented Jan 23, 2023

https://pulpito.ceph.com/adking-2023-01-22_23:00:58-orch:cephadm-wip-adk-testing-2023-01-22-1523-distro-default-smithi/

lots of failures from infra stuff (re-imaging machines, installing things pre-test) so did a rerun of all failed and dead jobs, resulting in

https://pulpito.ceph.com/adking-2023-01-23_04:36:45-orch:cephadm-wip-adk-testing-2023-01-22-1523-distro-default-smithi/

Leaving us with 6 failures.

  • 3 failed jobs were the new test_set_mon_crush_locations test introduced in one of the PRs in the run. The test just isn't quite right yet, but it's not relevant in terms of whether we can merge other PRs
  • 2 instances of the staggered upgrade test issue (known issue) https://tracker.ceph.com/issues/58535
  • 1 instance of failing to install container selinux package (known issue) https://tracker.ceph.com/issues/57771

Overall, nothing that would block merging for anything other than the mon crush location PR.

@adk3798 adk3798 merged commit 45813ea into ceph:main Feb 13, 2023
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants