And just one more thing, I also created a user, then modified it (added) the placement: ceph:~ # radosgw-admin user modify --uid user2 --placement-id dp-extra1 ceph:~ # radosgw-admin user info --uid user2 | jq '.default_placement' "dp-extra1" But when trying to create a bucket for this user, I get an invalid location constraint error (excerpt from aws s3 mb command with --debug flag): b'<?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidLocationConstraint</Code><Message></Message><BucketName>bucket2</BucketName><RequestId>tx00000562a28aefb02ae90-0069dfa16e-161851-default</RequestId><HostId>161851-default-default</HostId></Error>' Sorry for highjacking this thread, I can create a new one if necessary. Thanks! Eugen Zitat von Eugen Block <eblock@nde.ag>:
Hi,
I just re-ran my test on a lab cluster (19.2.3) and have a default zonegroup/zone. Then I add a new placement to zg/zone successfully ("dp-extra1" is the new placement):
soc9-ceph:~ # radosgw-admin zone placement list [ { "key": "default-placement", "val": { "index_pool": "default.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "default.rgw.buckets.data" } }, "data_extra_pool": "default.rgw.buckets.non-ec", "index_type": 0 } }, { "key": "dp-extra1", "val": { "index_pool": "dp-ceph-rgw-custom-index", "storage_classes": { "STANDARD": { "data_pool": "dp-ceph-rgw-custom-data" } }, "data_extra_pool": "dp-ceph-rgw-custom-non-ec", "index_type": 0 } } ]
But when I try to create a bucket in the Dashboard there's no custom placement, only the default placement.
Is this a limitation in the Dashboard? If it is, is there a way to create a bucket via CLI to use a specific placement target?
Thanks! Eugen
Zitat von Daniel Parkes <dparkes@redhat.com>:
Hi,
Yes, we have it in the docs, https://docs.ceph.com/en/latest/radosgw/placement/#placement-targets :
[image: image.png]
On Wed, Apr 15, 2026 at 2:06 PM Eugen Block via ceph-users < ceph-users@ceph.io> wrote:
It didn't work in my tests without a realm, so I don't believe grok :-D But I'd love to be proven wrong.
Zitat von Rok Jaklič <rjaklic@gmail.com>:
There is:
[root@ctplmon1 ~]# radosgw-admin realm list { "default_info": "", "realms": [] } [root@ctplmon1 ~]# radosgw-admin realm get-default No default realm is set [root@ctplmon1 ~]# radosgw-admin period list { "periods": [] } [root@ctplmon1 ~]# radosgw-admin zonegroup list { "default_info": "b1e0d55c-f7cb-4e73-b1cb-6cffa1fd6578", "zonegroups": [ "default" ] } [root@ctplmon1 ~]# radosgw-admin zone list { "default_info": "c2c70444-7a41-4acd-a0d0-9f87d324ec72", "zones": [ "default" ] }
Since there is no realm set, I can skip radosgw-admin period update --commit entirely if grok is to be believed?
On Wed, Apr 15, 2026 at 11:54 AM Eugen Block via ceph-users < ceph-users@ceph.io> wrote:
From my understanding the new placement will not be available if the period can't be updated. Your zonegroup/zone configuration seems off compared to the test cluster. Is there a default zonegroup/zone?
Zitat von Rok Jaklič via ceph-users <ceph-users@ceph.io>:
So I've created a little plan on how to create a new profile and assign new S3 users to EC 8+3 pool. Idea is that all new s3 users are using a new pool, and old ones pool with EC 3+2 and data is intact.
--- ceph osd erasure-code-profile set ec-83-profile k=8 m=3 crush-failure-domain=host ceph osd pool create rgw.buckets.ec-83.data 256 erasure ec-83-profile ceph osd pool application enable rgw.buckets.ec-83.data rgw
radosgw-admin zonegroup placement add --placement-id=ec-83-placement
radosgw-admin zone placement add \ --placement-id ec-83-placement \ --data-pool rgw.buckets.ec-83.data \ --index-pool default.rgw.buckets.index \ --data-extra-pool default.rgw.buckets.non-ec \ --placement-index-type 0
radosgw-admin period update --commit
# restart rgw systemctl restart ceph-radosgw.target # verify the new placement radosgw-admin zone get | grep -A 20 "ec-83-placement"
# for new s3 users, set the default placement radosgw-admin user create --uid=<user> --tenant=<tenant> --placement-id=ec-83-placement ---
It seems to work on "test cluster", however I get an error on:
[root@a8-mon1 ~]# radosgw-admin period update --commit cannot commit period: period does not have a master zone of a master zonegroup failed to commit period: (22) Invalid argument
Do I actually need to run this command or is "rgw restart" enough?
Any comments appriciated.
Rok
On Fri, Apr 3, 2026 at 12:42 PM Rok Jaklič via ceph-users < ceph-users@ceph.io> wrote:
> Hi, > > we expanded the cluster to 12 nodes with 28 osds, but we are still running > on EC 3+2, since we started cluster with 6 nodes. We would like to change > it to EC 6+3 or even EC 8+3? Is this reasonable or will 8+3 take too much > CPU/network capacities? Should I use isa/isa-l instead of jerasure? > > Can anyone share experience with 8+3? > > Kind regards, > Rok > _______________________________________________ > ceph-users mailing list -- ceph-users@ceph.io > To unsubscribe send an email to ceph-users-leave@ceph.io > _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io