We have successfully deployed with decreased number of pg_num (128 per pool ).
Then we increased it manually -- all is working.
So as we see in our case ceph cluster can not handle PGs creation during adding new OSDs due to big number of pg_num and OSDs :). To investigate why we need this cluster and hence more time.
Now we have some quick solutions:
1. Mykola Golub says that we have incorrect calculation formula for pg_num and he already has blueprint(https://blueprints.launchpad.net/fuel/+spec/ceph-osd-pool-default-pg-num).
We would like to try to deploy with Mykolas formula and see whether it fixes the problem.
2. Also we have an option to postpone ceph pool creation to time when deployment of ceph OSDs is finished (post deployment task). It cant prevent ceph cluster from handling cases when OSD are added and PGs are greated.
We would like to try it too.
If we do it we will make decision and prepare the patch.
We have successfully deployed with decreased number of pg_num (128 per pool ).
Then we increased it manually -- all is working.
So as we see in our case ceph cluster can not handle PGs creation during adding new OSDs due to big number of pg_num and OSDs :). To investigate why we need this cluster and hence more time.
Now we have some quick solutions: /blueprints. launchpad. net/fuel/ +spec/ceph- osd-pool- default- pg-num).
1. Mykola Golub says that we have incorrect calculation formula for pg_num and he already has blueprint(https:/
We would like to try to deploy with Mykolas formula and see whether it fixes the problem.
2. Also we have an option to postpone ceph pool creation to time when deployment of ceph OSDs is finished (post deployment task). It cant prevent ceph cluster from handling cases when OSD are added and PGs are greated.
We would like to try it too.
If we do it we will make decision and prepare the patch.