- ceph-users - lists.ceph.io

Re: Unable to reshard bucket
by Eric Ivancich 25 Nov '20

25 Nov '20

Hey Timothy, Did you ever resolve this issue, and if so, how? > Thank you..I looked through both logs and noticed this in the cancel one: > > osd_op(unknown.0.0:4164 41.2 41:55b0279d:reshard::reshard.0000000009:head [call > rgw.reshard_remove] snapc 0=[] ondisk+write+known_if_redirected e24984) v8 -- > 0x7fe9b3625710 con 0 > osd_op_reply(4164 reshard.0000000009 [call] v24984'105796943 uv105796922 ondisk = -2 > ((2) No such file or directory)) v8 ==== 162+0+0 (203651653 0 0) 0x7fe9880044a0 con > 0x7fe9b3625b70 > ERROR: failed to remove entry from reshard log, oid=reshard.0000000009 tenant= bucket=foo > > Is there anything else that I should look for? It looks like the cancel process thinks > that reshard.0000000009 is present (and probably blocking my attempts at resharding) but > it's not actually there and thus can't be removed. Eric -- J. Eric Ivancich he / him / his Red Hat Storage Ann Arbor, Michigan, USA

3 4

November Ceph Science User Group Virtual Meeting
by Kevin Hrpcek 25 Nov '20

25 Nov '20

Hey all, We will be having a Ceph science/research/big cluster call on Wednesday November 25th. If anyone wants to discuss something specific they can add it to the pad linked below. If you have questions or comments you can contact me. This is an informal open call of community members mostly from hpc/htc/research environments where we discuss whatever is on our minds regarding ceph. Updates, outages, features, maintenance, etc...there is no set presenter but I do attempt to keep the conversation lively. https://pad.ceph.com/p/Ceph_Science_User_Group_20201125 <https://pad.ceph.com/p/Ceph_Science_User_Group_20201125> <https://pad.ceph.com/p/Ceph_Science_User_Group_20200923> We try to keep it to an hour or less. Ceph calendar event details: November 25th, 2020 15:00 UTC 4pm Central European 9am Central US Description: Main pad for discussions: https://pad.ceph.com/p/Ceph_Science_User_Group_Index Meetings will be recorded and posted to the Ceph Youtube channel. To join the meeting on a computer or mobile phone: https://bluejeans.com/908675367?src=calendarLink To join from a Red Hat Deskphone or Softphone, dial: 84336. Connecting directly from a room system? 1.) Dial: 199.48.152.152 or bjn.vc 2.) Enter Meeting ID: 908675367 Just want to dial in on your phone? 1.) Dial one of the following numbers: 408-915-6466 (US) See all numbers: https://www.redhat.com/en/conference-numbers 2.) Enter Meeting ID: 908675367 3.) Press # Want to test your video connection? https://bluejeans.com/111 Kevin -- Kevin Hrpcek NASA VIIRS Atmosphere SIPS Space Science & Engineering Center University of Wisconsin-Madison

2 1

Re: Misleading error (osd has already bound to class) when starting osd on nautilus?
by David Caro 25 Nov '20

25 Nov '20

Forwarding here in case anyone is seeing the same/similar issue, Amit gave really good pointers and a workaround :) Thanks Amit! On 11/25 16:08, Amit Ghadge wrote: > Yes, and if you want avoid in future update this flag to 0 by $echo 0 > > /sys/block/sdx/queue/rotational > > Thanks > > On Wed, Nov 25, 2020 at 4:03 PM David Caro <dcaro(a)wikimedia.org> wrote: > > > > > Yep, you are right: > > > > ``` > > # cat /sys/block/sdd/queue/rotational > > 1 > > ``` > > > > I was looking to the code too but you got there before me :) > > > > https://github.com/ceph/ceph/blob/25ac1528419371686740412616145703810a561f/… > > > > > > It might be an issue with the driver then reporting the wrong data. I'll > > look > > into it. > > > > Do you mind if I reply on the list with this info? (or if you want you > > reply) > > I think this might help others too (and myself in the future xd) > > > > Thanks Amit! > > > > On 11/25 15:50, Amit Ghadge wrote: > > > This might happen when the disk default sets 1 > > > in /sys/block/sdx/queue/rotational , 1 for HDD and 0 for SSD, But we not > > > see any problem till now. > > > > > > -AmitG > > > > > > On Wed, Nov 25, 2020 at 3:08 PM David Caro <dcaro(a)wikimedia.org> wrote: > > > > > > > > > > > Hi! > > > > > > > > I have a nautilus ceph cluster, and today I restarted one of the osd > > > > daemons > > > > and spend some time trying to debug an error I was seeing in the log, > > > > though it > > > > seems the osd is actually working. > > > > > > > > > > > > The error I was seeing is: > > > > ``` > > > > Nov 25 09:07:43 osd15 systemd[1]: Starting Ceph object storage daemon > > > > osd.44... > > > > Nov 25 09:07:43 osd15 systemd[1]: Started Ceph object storage daemon > > > > osd.44. > > > > Nov 25 09:07:47 osd15 ceph-osd[12230]: 2020-11-25 09:07:47.846 > > > > 7f55395fbc80 -1 osd.44 106947 log_to_monitors {default=true} > > > > Nov 25 09:07:47 osd15 ceph-osd[12230]: 2020-11-25 09:07:47.850 > > > > 7f55395fbc80 -1 osd.44 106947 mon_cmd_maybe_osd_create fail: 'osd.44 > > has > > > > already bound to class 'ssd', can not reset class to 'hdd'; use 'ceph > > osd > > > > crush rm-device-class <id>' to remove old class first': (16) Device or > > > > resource busy > > > > ``` > > > > > > > > There's no other messages in the journal so at first I thought that > > the osd > > > > failed to start. > > > > But it seems to be up and working correctly anyhow. > > > > > > > > There's no "hdd" class in my crush map: > > > > ``` > > > > # ceph osd crush class ls > > > > [ > > > > "ssd" > > > > ] > > > > ``` > > > > > > > > And that osd is actually of the correct class: > > > > ``` > > > > # ceph osd crush get-device-class osd.44 > > > > ssd > > > > ``` > > > > > > > > ``` > > > > # uname -a > > > > Linux osd15 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 > > (2020-06-07) > > > > x86_64 GNU/Linux > > > > > > > > # ceph --version > > > > ceph version 14.2.5-1-g23e76c7aa6 > > > > (23e76c7aa6e15817ffb6741aafbc95ca99f24cbb) nautilus (stable) > > > > ``` > > > > > > > > The osd shows up in the cluster and it's receiving load, so there > > seems to > > > > be > > > > no problem, but does anyone know what that error is about? > > > > > > > > > > > > Thanks! > > > > > > > > > > > > -- > > > > David Caro > > > > SRE - Cloud Services > > > > Wikimedia Foundation <https://wikimediafoundation.org/> > > > > PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 > > > > > > > > "Imagine a world in which every single human being can freely share in > > the > > > > sum of all knowledge. That's our commitment." > > > > _______________________________________________ > > > > ceph-users mailing list -- ceph-users(a)ceph.io > > > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > > > > > > > > -- > > David Caro > > SRE - Cloud Services > > Wikimedia Foundation <https://wikimediafoundation.org/> > > PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 > > > > "Imagine a world in which every single human being can freely share in the > > sum of all knowledge. That's our commitment." > > -- David Caro SRE - Cloud Services Wikimedia Foundation <https://wikimediafoundation.org/> PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."

2 1

DocuBetter Meeting Today
by John Zachary Dover 25 Nov '20

25 Nov '20

There is a general documentation meeting called the "DocuBetter Meeting", and it is held every two weeks. The next DocuBetter Meeting will be on Nov 26, 2020 at 0200 UTC, and will run for thirty minutes. Everyone with a documentation-related request or complaint is invited. The meeting will be held here: https://bluejeans.com/908675367 (Since this particular instance of this meeting will be held on the Wednesday before United States Thanksgiving, I expect a light turnout.) Send documentation-related requests and complaints to me by replying to this email and CCing me at zac.dover(a)gmail.com. The next DocuBetter meeting is scheduled for: 26 Nov 2020 0200 UTC Etherpad: https://pad.ceph.com/p/Ceph_Documentation Meeting: https://bluejeans.com/908675367 Thanks, everyone. Zac Dover

1 0

uniform and list crush bucket algorithm usage in data centers
by Bobby 25 Nov '20

25 Nov '20

Hi all, For placement purposes ceph uses the default straw2 bucket algorithm. I am curious if the other two bucket algorithms like uniform and list are also being used in some present use cases in data centers? Are there any use cases where straw2 is not being used at all ? BR

1 0

KeyError: 'targets' when adding second gateway on ceph-iscsi - BUG
by Hamidreza Hosseini 25 Nov '20

25 Nov '20

Hi, I have installed ceph-iscsi on ubuntu 20 manully, But when I want to add second gateway it will show me error: ``` OS: Ubuntu 20 LTS ceph version : octopus I install cluster with ceph-ansible but I install ceph-iscsi manually via following link: https://docs.ceph.com/en/latest/rbd/iscsi-target-cli/ (instead of 'yum install ceph-iscsi' I commit 'apt install ceph-iscsi') root@dev13:~# gwcli -v gwcli - 2.7 ``` ``` /iscsi-target...-igw/gateways> create ceph-gateway1 192.168.200.33 Adding gateway, sync'ing 0 disk(s) and 0 client(s) KeyError: 'targets' ``` and it will jump out of gwcli! this is my gwcli log: ``` root@dev13:~# cat gwcli.log 2020-11-25 14:24:56,440 DEBUG [ceph.py:32:__init__()] Adding ceph cluster 'ceph' to the UI 2020-11-25 14:24:57,049 DEBUG [ceph.py:241:populate()] Fetching ceph osd information 2020-11-25 14:24:57,086 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:24:57,197 DEBUG [storage.py:105:refresh()] Refreshing disk information from the config object 2020-11-25 14:24:57,197 DEBUG [storage.py:108:refresh()] - Scanning will use 8 scan threads 2020-11-25 14:24:57,254 DEBUG [storage.py:135:refresh()] - rbd image scan complete: 0s 2020-11-25 14:24:57,254 DEBUG [gateway.py:378:refresh()] Refreshing gateway & client information 2020-11-25 14:24:57,254 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:24:57,294 DEBUG [ceph.py:260:refresh()] Gathering pool stats for cluster 'ceph' 2020-11-25 14:25:02,319 DEBUG [ceph.py:32:__init__()] Adding ceph cluster 'ceph' to the UI 2020-11-25 14:25:03,076 DEBUG [ceph.py:241:populate()] Fetching ceph osd information 2020-11-25 14:25:03,168 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:25:03,219 DEBUG [storage.py:105:refresh()] Refreshing disk information from the config object 2020-11-25 14:25:03,219 DEBUG [storage.py:108:refresh()] - Scanning will use 8 scan threads 2020-11-25 14:25:03,273 DEBUG [storage.py:135:refresh()] - rbd image scan complete: 0s 2020-11-25 14:25:03,274 DEBUG [gateway.py:378:refresh()] Refreshing gateway & client information 2020-11-25 14:25:03,274 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:25:03,314 DEBUG [ceph.py:260:refresh()] Gathering pool stats for cluster 'ceph' 2020-11-25 14:25:32,950 DEBUG [ceph.py:32:__init__()] Adding ceph cluster 'ceph' to the UI 2020-11-25 14:25:33,614 DEBUG [ceph.py:241:populate()] Fetching ceph osd information 2020-11-25 14:25:33,652 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:25:33,714 DEBUG [storage.py:105:refresh()] Refreshing disk information from the config object 2020-11-25 14:25:33,714 DEBUG [storage.py:108:refresh()] - Scanning will use 8 scan threads 2020-11-25 14:25:33,811 DEBUG [storage.py:135:refresh()] - rbd image scan complete: 0s 2020-11-25 14:25:33,811 DEBUG [gateway.py:378:refresh()] Refreshing gateway & client information 2020-11-25 14:25:33,811 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:25:33,864 DEBUG [ceph.py:260:refresh()] Gathering pool stats for cluster 'ceph' 2020-11-25 14:26:02,665 DEBUG [gateway.py:174:ui_command_create()] CMD: /iscsi create iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw 2020-11-25 14:26:02,666 DEBUG [gateway.py:185:ui_command_create()] Create an iscsi target definition in the UI 2020-11-25 14:26:03,191 INFO [gateway.py:196:ui_command_create()] ok 2020-11-25 14:26:45,455 DEBUG [gateway.py:793:ui_command_create()] CMD: ../gateways/ create dev13 ['192.168.200.23'] nosync=False skipchecks=false 2020-11-25 14:26:45,467 INFO [gateway.py:836:ui_command_create()] Adding gateway, sync'ing 0 disk(s) and 0 client(s) 2020-11-25 14:26:45,949 DEBUG [gateway.py:854:ui_command_create()] Gateway creation successful 2020-11-25 14:26:45,949 DEBUG [gateway.py:855:ui_command_create()] Adding gw to UI 2020-11-25 14:26:45,968 DEBUG [gateway.py:934:refresh()] - checking iSCSI/API ports on dev13 2020-11-25 14:26:45,979 INFO [gateway.py:874:ui_command_create()] ok 2020-11-25 14:28:41,572 DEBUG [ceph.py:32:__init__()] Adding ceph cluster 'ceph' to the UI 2020-11-25 14:28:42,269 DEBUG [ceph.py:241:populate()] Fetching ceph osd information 2020-11-25 14:28:42,297 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:28:42,334 DEBUG [storage.py:105:refresh()] Refreshing disk information from the config object 2020-11-25 14:28:42,334 DEBUG [storage.py:108:refresh()] - Scanning will use 8 scan threads 2020-11-25 14:28:42,378 DEBUG [storage.py:135:refresh()] - rbd image scan complete: 0s 2020-11-25 14:28:42,378 DEBUG [gateway.py:378:refresh()] Refreshing gateway & client information 2020-11-25 14:28:42,449 DEBUG [gateway.py:934:refresh()] - checking iSCSI/API ports on dev13 2020-11-25 14:28:42,463 DEBUG [ceph.py:150:update_state()] Querying ceph for state information 2020-11-25 14:28:42,517 DEBUG [ceph.py:260:refresh()] Gathering pool stats for cluster 'ceph' 2020-11-25 14:28:52,659 DEBUG [gateway.py:793:ui_command_create()] CMD: ../gateways/ create ceph-gateway1 ['192.168.200.33'] nosync=False skipchecks=false 2020-11-25 14:28:52,672 INFO [gateway.py:836:ui_command_create()] Adding gateway, sync'ing 0 disk(s) and 0 client(s) 2020-11-25 14:28:53,406 DEBUG [gateway.py:854:ui_command_create()] Gateway creation successful 2020-11-25 14:28:53,407 DEBUG [gateway.py:855:ui_command_create()] Adding gw to UI ``` ``` root@dev13:~# sudo gwcli export copy { "created": "2020/11/25 10:54:39", "discovery_auth": { "mutual_password": "", "mutual_password_encryption_enabled": false, "mutual_username": "", "password": "", "password_encryption_enabled": false, "username": "" }, "disks": {}, "epoch": 2, "gateways": { "dev13": { "active_luns": 0, "created": "2020/11/25 10:56:45", "updated": "2020/11/25 10:56:45" } }, "targets": { "iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw": { "acl_enabled": true, "auth": { "mutual_password": "", "mutual_password_encryption_enabled": false, "mutual_username": "", "password": "", "password_encryption_enabled": false, "username": "" }, "clients": {}, "controls": {}, "created": "2020/11/25 10:56:02", "disks": {}, "groups": {}, "ip_list": [ "192.168.200.23" ], "portals": { "dev13": { "gateway_ip_list": [ "192.168.200.23" ], "inactive_portal_ips": [], "portal_ip_addresses": [ "192.168.200.23" ], "tpgs": 1 } }, "updated": "2020/11/25 10:56:45" } }, "updated": "2020/11/25 10:56:45", "version": 11 } ``` I even changed python3 to python2 but I have the same issue but in the proccess of defining iqn. What should I do for this problem?

1 0

Re: Documentation of older Ceph version not accessible anymore on docs.ceph.com
by John Zachary Dover 25 Nov '20

25 Nov '20

I'll carry this message to the Leadership Team this week and, if Thanksgiving proves an impediment to addressing it, next week. Thanks for raising this concern. Zac Dover Upstream Docs Ceph On Wed, Nov 25, 2020 at 1:43 AM Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote: > > > 2nd that. Why even remove old documentation before it is migrated to the > new environment. It should be left online until the migration > successfully completed. > > > > -----Original Message----- > Sent: Tuesday, November 24, 2020 4:23 PM > To: Frank Schilder > Cc: ceph-users > Subject: [ceph-users] Re: Documentation of older Ceph version not > accessible anymore on docs.ceph.com > > I want to just echo this sentiment. I thought the lack of older docs > would be a very temporary issue, but they are still not available. It is > especially frustrating when half the google searches also return a page > not found error. The migration has been very badly done. > > Sincerely, > > On Tue, Nov 24, 2020 at 2:52 AM Frank Schilder <frans(a)dtu.dk> wrote: > > > Older versions are available here: > > > > > > https://web.archive.org/web/20191226012841/https://docs.ceph.com/docs/ > > mimic/ > > > > I'm actually also a bit unhappy about older versions missing. Mimic is > > > not end of life and a lot of people still use luminous. Since there > > are such dramatic differences between interfaces, the old docs should > > not just disappear. > > > > Best regards, > > ================= > > Frank Schilder > > AIT Risø Campus > > Bygning 109, rum S14 > > > > ________________________________________ > > From: Dan Mick <dmick(a)redhat.com> > > Sent: 24 November 2020 01:53:29 > > To: Martin Palma > > Cc: ceph-users > > Subject: [ceph-users] Re: Documentation of older Ceph version not > > accessible anymore on docs.ceph.com > > > > I don't know the answer to that. > > > > On 11/23/2020 6:59 AM, Martin Palma wrote: > > > Hi Dan, > > > > > > yes I noticed but now only "latest", "octopus" and "nautilus" are > > > offered to be viewed. For older versions I had to go directly to > > > github. > > > > > > Also simply switching the URL from > > > "https://docs.ceph.com/en/nautilus/" to > > > "https://docs.ceph.com/en/luminous/" will not work any more. > > > > > > Is it planned to make the documentation of the older version > > > available again through doc.ceph.com? > > > > > > Best, > > > Martin > > > > > > On Sat, Nov 21, 2020 at 2:11 AM Dan Mick <dmick(a)redhat.com> wrote: > > >> > > >> On 11/14/2020 10:56 AM, Martin Palma wrote: > > >>> Hello, > > >>> > > >>> maybe I missed the announcement but why is the documentation of > > >>> the older ceph version not accessible anymore on docs.ceph.com > > >> > > >> It's changed UI because we're hosting them on readthedocs.com now. > > > >> See the dropdown in the lower right corner. > > >> > > > > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an > > email to ceph-users-leave(a)ceph.io > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an > > email to ceph-users-leave(a)ceph.io > > > > > -- > Steven Pine > > *E * steven.pine(a)webair.com | *P * 516.938.4100 x > *Webair* | 501 Franklin Avenue Suite 200, Garden City NY, 11530 > webair.com > [image: Facebook icon] <https://www.facebook.com/WebairInc/> [image: > Twitter icon] <https://twitter.com/WebairInc> [image: Linkedin icon] > <https://www.linkedin.com/company/webair> > NOTICE: This electronic mail message and all attachments transmitted > with it are intended solely for the use of the addressee and may contain > legally privileged proprietary and confidential information. If the > reader of this message is not the intended recipient, or if you are an > employee or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any dissemination, > distribution, copying, or other use of this message or its attachments > is strictly prohibited. If you have received this message in error, > please notify the sender immediately by replying to this message and > delete it from your computer. > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an > email to ceph-users-leave(a)ceph.io > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

1 0

Re: Ceph on ARM ?
by Kevin Thorpe 25 Nov '20

25 Nov '20

Sorry, I can't compare. Not used Ceph in anger anywhere else. In our case we were looking for Kubernetes on-premises storage and several points led us to the Ambedded solution. I wouldn't expect them to have the sort of throughput of a full size Xeon server but for our immediate purposes that is not really an issue. - It was a turnkey solution with support. We knew very little about either Kubernetes or Ceph and this was the least risk for us. - Size and power. We only have single racks in two datacentres, space is a serious consideration. Ceph is very machine hungry and the alternatives like Softiron even ran to 7U at least. We get 24 micro servers in 3U. Power is only 105W per unit along with little heat. - Cost. These appliances are incredibly inexpensive for the amount of storage they provide. Even the smallest offerings from people like Dell/EMC were both a lot larger and an astonomical amount more expensive. The licencing is purely related to the physical appliances. Hard drives and M.2 cache can be upgraded. You can even run on a single appliance albeit at much reduced resilience and lost capacity. Makes evaluation really inexpensive. - Open source standard. Anything we learn from running these appliances is directly translatable to any Ceph install. Anything we learned on Dell/EMC would be yet more lock in to Dell/EMC. We intend to experiment with Rook in the near future but our inexperience of both Kubernetes and Ceph made this option too risky for the initial stages. If we run Rook properly we think we can be able to co-locate things like databases with their OSD and storage on one server so that performance is optimal while having the management control of Ceph. But the bulk of our data storage is exactly that and doesn't require massive performance. On Wed, 25 Nov 2020 at 09:35, Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote: > > How does ARM compare to Xeon in latency and cluster utilization? > > > >

1 0

Misleading error (osd has already bound to class) when starting osd on nautilus?
by David Caro 25 Nov '20

25 Nov '20

Hi! I have a nautilus ceph cluster, and today I restarted one of the osd daemons and spend some time trying to debug an error I was seeing in the log, though it seems the osd is actually working. The error I was seeing is: ``` Nov 25 09:07:43 osd15 systemd[1]: Starting Ceph object storage daemon osd.44... Nov 25 09:07:43 osd15 systemd[1]: Started Ceph object storage daemon osd.44. Nov 25 09:07:47 osd15 ceph-osd[12230]: 2020-11-25 09:07:47.846 7f55395fbc80 -1 osd.44 106947 log_to_monitors {default=true} Nov 25 09:07:47 osd15 ceph-osd[12230]: 2020-11-25 09:07:47.850 7f55395fbc80 -1 osd.44 106947 mon_cmd_maybe_osd_create fail: 'osd.44 has already bound to class 'ssd', can not reset class to 'hdd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy ``` There's no other messages in the journal so at first I thought that the osd failed to start. But it seems to be up and working correctly anyhow. There's no "hdd" class in my crush map: ``` # ceph osd crush class ls [ "ssd" ] ``` And that osd is actually of the correct class: ``` # ceph osd crush get-device-class osd.44 ssd ``` ``` # uname -a Linux osd15 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux # ceph --version ceph version 14.2.5-1-g23e76c7aa6 (23e76c7aa6e15817ffb6741aafbc95ca99f24cbb) nautilus (stable) ``` The osd shows up in the cluster and it's receiving load, so there seems to be no problem, but does anyone know what that error is about? Thanks! -- David Caro SRE - Cloud Services Wikimedia Foundation <https://wikimediafoundation.org/> PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."

1 0

S3 Object Lock - ceph nautilus
by Torsten Ennenbach 25 Nov '20

25 Nov '20

We are running our S3 Ceph Cluster on Nautilus 14.2.9 and want to use features like Object-lock-enabled. A creation of a bucket is possible with: aws s3api create-bucket --bucket locktest --endpoint http://our-s3 <http://our-s3/> --object-lock-enabled-for-bucket & aws s3api put-object-lock-configuration --bucket locktest --endpoint http://our-s3 <http://our-s3/> --object-lock-configuration '{ "ObjectLockEnabled“: "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 50 }}}‘ Are still deletable, and we don’t know why. Because this feature was backported to 14.2.5 as you can see here: https://github.com/ceph/ceph/pull/29905 <https://github.com/ceph/ceph/pull/29905> Any idea what we are doing wrong? -- Beste Grüße aus Köln Ehrenfeld Torsten Ennenbach Cloud Architect

1 0