Oh dear, please ignore my last two emails. I feel kind of stupid, but I needed to restart the RGW daemon. Now I can use the custom placement. :-D Sorry for the noise... Zitat von Eugen Block <eblock@nde.ag>:
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