Description of problem: The deployment of the overcloud failed due to the insufficient amount of OSDs per PGs. In this deployment, CephPoolDefaultPgNum is set to 32. All of the OpenStack related pools, volumes, images and vms are set with 32 PGs as needed, but the manila_data pool was set to 128. Version-Release number of selected component (if applicable): ceph-ansible-3.1.0-0.1.rc9.el7cp.noarch openstack-tripleo-validations-8.4.1-5.el7ost.noarch python-tripleoclient-9.2.1-12.el7ost.noarch puppet-tripleo-8.3.2-8.el7ost.noarch openstack-tripleo-common-containers-8.6.1-20.el7ost.noarch openstack-tripleo-puppet-elements-8.0.0-2.el7ost.noarch openstack-tripleo-common-8.6.1-20.el7ost.noarch openstack-tripleo-heat-templates-8.0.2-38.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Set the storage environment file with the parameter CephPoolDefaultPgNum to 32 2. call the environment files: /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config-docker.yaml /usr/share/openstack-tripleo-heat-templates/environments/services/ceph-mds.yaml 3. deploy Actual results: The deployment fails, the manila pools are have too many PGs (128) - Ceph-ansible verification is failing Expected results: The manila pools are set with 32 PGs Additional info:
This is expected, the cephfs pools have their own parameters [1] [2] to set the PG num. Do you think it would be more intuitive to default these to the DefaultPgNum value? 1. https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mds.yaml#L41 2. https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mds.yaml#L47
(In reply to Giulio Fidente from comment #1) > This is expected, the cephfs pools have their own parameters [1] [2] to set > the PG num. > > Do you think it would be more intuitive to default these to the DefaultPgNum > value? Yes, I do. In any case, this should be documented properly to avoid future errors
Verified
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:0283