The quay.io/ceph/daemon:latest-pacific image is also stuck on 16.2.5.
Only the quay.io/ceph/ceph:v16 image seems to be up to date, but I can't
get it to start the daemons.
On 30/05/2022 14:54, Janek Bevendorff wrote:
Was this announced somewhere? Could this not wait till Pacific is EOL, so we
Den mån 30 maj 2022 kl 22:07 skrev Jeremy Hansen :
>
> Any chance you could point me to the specific documentation that explains how
> to do a clean shut down? I’m having trouble finding it in the official docs.
>
https://old.ceph.com/planet/how-to-do-a-ceph-cluster-maintenance-shutdown/
--
M
What you could try is to increase the delete_sleep for the OSDs.
ceph tell osd.* injectargs '--osd_delete_sleep 30'
I had a customer that ran into similar issues, terrible performance on snapshot
removal. They ended up setting it to 30 to reduce the impact on performance.
You might start at
Hi all,
it seems to be the time of stuck MDSs. We also have our ceph filesystem
degraded. The MDS is stuck in replay for about 20 hours now.
We run a nautilus ceph cluster with about 300TB of data and many
millions of files. We run two MDSs with a particularly large directory
pinned to one of them
Hi cephers,
Auto invite URL and bridge bot are now UP.
The IRC-slack auto invite url has changed, please use the following
https://slack.openinfra.mx/
Sorry about the testing noise.
Cheers.
On Mon, May 30, 2022 at 6:28 PM Alvaro Soto wrote:
> Hey cephers
> I'll be migrating the auto-invite
Hi,
This is an issue I've been having since at least Ceph 15.x and I haven't
found a way around it yet. I have a bunch of radosgw nodes in a
Kubernetes cluster (using the ceph/ceph-daemon Docker image) and once
every few container restarts, the daemon decides to crash at startup for
unknown r
Hi,
we are applying the RBD snapshots on images on Ceph with hourly schedule
and 1 day retention.
When I run `ceph osd pool ls detail` command I can see a lot of in
removed_snaps_queue and some few in removed_snaps.
Can someone explain what does it mean and if I should give extra
attention
Okay, after writing this mail, I might have found what's wrong.
The message
monclient(hunting): handle_auth_bad_method server allowed_methods [2]
but i only support [2]
makes no sense, but it pointed me to something else when I had a pod
that refused to start even after deleting it multiple
Can I host multiple zones from different realms in one data pool?
All object names in a data pool start with a pool ID. I can specify the
same data_pool for multiple zones and this looks like a workaround, but I'm
not sure if this won't be a problem in the future.
__
All object names in a data pool start with a zone ID. (typo)
вт, 31 мая 2022 г. в 17:07, Dmitry Kvashnin :
> Can I host multiple zones from different realms in one data pool?
> All object names in a data pool start with a pool ID. I can specify the
> same data_pool for multiple zones and this loo
This is caused by an object that does not yet have a bucket associated
with it. It doesn't happen in S3, because S3 doesn't set_atomic() that
early, and it's fixed on main by the objctx removal (which is too
complicated for backport). Can you open a tracker for this, so that we
can get a fix
I found a solution here:
https://www.reddit.com/r/ceph/comments/ut9lag/recover_from_module_progress_has_failed/
Turns out, you can just fail over the MGR and it will reset the progress
module: `ceph mgr fail`
Now the cluster is healthy and can be upgraded to a version where this
issue is fixed.
Hello
On a new cluster, installed with cephadm, I have prepared news osd for separate
al and db
To do it I follow this doc :
https://docs.ceph.com/en/quincy/rados/configuration/bluestore-config-ref/
I run ceph version 17.2.0
When I shoot the ceph-volume creation I got this error
root@store-par
Ok forget this, I have follow another way
ceph orch apply -i osd_spec.yaml
with this conf
osd_spec.yaml
service_type: osd
service_id: osd_spec_default
placement:
host_pattern: '*'
data_devices:
rotational: 1
db_devices:
paths:
- /dev/nvme0n1
- /dev/nvme1n1
- Mail original
I'm having trouble adding a secondary zone RGW using cephadm, running with ceph
16.2.9.
The master realm, zonegroup, and zone are already configured and working on
another cluster.
This is a new cluster configured with cephadm, everything is up and running but
when I try to add an RGW and creat
After new research and some troubleshooting tips I´ve found that editing
the "iscsi-gateway.cfg" file manually and inserting the "api_host" variable
makes the container start normally. But it can only be done after the
service is deployed because containers are dynamically created by cephadm.
After
Problem solved - 2 of the pools (zone-2.rgw.meta and zone-2.rgw.log) did not
have the "rgw" application enabled. Once that was fixed, it started working.
From: Wyll Ingersoll
Sent: Tuesday, May 31, 2022 3:51 PM
To: ceph-users@ceph.io
Subject: [ceph-users] Addi
17 matches
Mail list logo
