Hi everyone,
Our next Ceph Developer Monthly will be next week,
Wed Jul 10 at 9PM ET, or
Thu Jul 11 at 0100 UTC
The agenda:
https://tracker.ceph.com/projects/ceph/wiki/CDM_10-JUL-2019
The current topics are all RADOS related:
- Network ping monitoring: better monitoring and reporting of latencies
between OSDs.
- Muting health warnings: adding the ability to mute health alerts for
some period of time via CLI or GUI.
- Slow request diagnostics: improving our overall behavior (reporting,
diagnosability, etc) when things aren't going quite right (slow/busy disk,
CPU bottleneck, slow requests, OMAP slow requests, etc)
If you have other topics you'd like to discuss, reply to this email or add
them to the wiki agenda (linked above).
Thanks!
sage
FYI -- Odd notice about my response being held when responding to
Yuri's validation status email: "Message has more than 10 recipients"
---------- Forwarded message ---------
From: <dev-bounces(a)ceph.io>
Date: Tue, Jul 2, 2019 at 12:45 PM
Subject: Your message to dev(a)ceph.io awaits moderator approval
To: <jdillama(a)redhat.com>
Your mail to 'dev(a)ceph.io' with the subject
Re: 14.2.2 QE Nautilus validation status
Is being held until the list moderator can review it for approval.
The message is being held because:
Message has more than 10 recipients
Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
--
Jason
All,
especially in the Ceph Orchestrator world, we're facing an issue where
we don't have a place for for Python code that can be imported by the
MGR and by tools that deploy Ceph.
Having a Library for common Python code would also provide a way to ease
some other Python related problems (also orchestrator independent):
1. There is duplicated code in the cython bindings. Especially the
Exceptions are duplicated for each binding.
2. There is no good way to share Python code between different tools
written in Pyhton
3. There is no way to share common code, like e.g. common data
structures between the different layers of the Orchestrator stacks.
4. There is no statically type-checkable Python API for the (mon)
command API.
5. The local Ceph version number is hard coded into the ceph cli binary
Now, the idea is to build a new Python package that is supposed to be
importable by everyone.
From a user's POV, this would look something like
>
> from ceph.mon_command_api import MonCommandApi
> from ceph.deployment_utils import DriveGroupSpec
> from ceph.exceptions import Error
>
> MonCommandApi(...).osd_pool_create(pool='my_pool', ...)
>
> try:
> ...
> except OSError:
> ...
What would be the scope of this library? Basically everything where
there is a real benefit for having it included, like sharing common code
between things. From the orchestrator, this could include common
deployment recipes. Or recipes used by the SSH orchestrator.
Some open questions are:
What about code that right now lives in the dashboard, like
pybind/mgr/dashboard.controllers.rbd.Rbd#_rbd_disk_usage
for calculating the RBD disk usage?
Where does it live in the ceph git? /src/python-common/ ?
How can we package it?
Python 2?
Thanks,
Sebastian
--
--
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg)
Hi,
Are there any plans to implement a per-client throttle on mds client requests?
We just had an interesting case where a new cephfs user was hammering
an mds from several hosts. In the end we found that their code was
doing:
while d=getafewbytesofdata():
f=open(file.dat)
f.append(d)
f.close()
By changing their code to:
f=open(file.dat)
while d=getafewbytesofdata():
f.append(d)
f.close()
it completely removes their load on the mds (for obvious reasons).
In a multi-user environment it's hard to scrutinize every user's
application, so we'd prefer to just throttle down the client req rates
(and let them suffer from the poor performance).
Thoughts?
Thanks,
Dan
Hi everyone,
The target release date for Octopus is March 1, 2020.
The freeze will be January 1, 2020. As a practical matter, that means any
features need to be in before people leave for the holidays, ensuring the
features get in in time and also that we can run tests over the holidays
while the test lab is relatively idle.
We plan to stick to a 12 month cadence going forward, so the P release
target would be March 1 2021 (regardless of whether Octopus is early or
late).
Thanks!
sage
We created dev(a)ceph.io several weeks back. There has been plenty of
time now for everyone to get subscribed, so please now direct all dev
discussion for Ceph proper to dev(a)ceph.io and use this list for
ceph kernel client development only. Avoid copying both lists unless the
discussion is relevant both for userspace and the kernel.
https://lists.ceph.io/postorius/lists/dev.ceph.io/
Thanks!
sage
Hi everyone,
I am currently working on a project where the Rados Gateway SSE-KMS
feature is required;
I cannot rely on the solution based on Barbican and Vault is the KMS of choice.
For these reason, here [1] a proposal to abstract the key management
service and an initial sketch for a refactoring strategy to support
HashiCorp Vault.
I am currently not planning on adding any new SSE strategy (such as
SSE-S3), although the refactoring might simplify its implementation.
Thanks.
[1] https://pad.ceph.com/p/rgw_sse-kms
--
Andrea Baglioni
Hello everyone,
Recently I was trying to expand an OSD disk using bluefs-bdev-expand.
Since this OSD is a virtual machine managed by oVirt, I first resized
the virtual disk of the virtual machine. The result from ''lsblk'' was:
vdb
252:16 0 200G 0 disk
└─ceph--bc94ec07--2ac3--4965--8750--bb9e42ec670f-osd--block--aa7de90e--0442--4cd9--9927--a17dd666ea74
253:2 0 100G 0 lvm
As you can see the block device /dev/vdb has 200G but the logical volume
is still 100G. I then used the following:
lvextend -L+100G
/dev/ceph--bc94ec07--2ac3--4965--8750--bb9e42ec670f/osd--block--aa7de90e--0442--4cd9--9927--a17dd666ea74
After using lvextend I then ran:
# ceph-bluestore-tool show-label --path /var/lib/ceph/osd/ceph-7/
inferring bluefs devices from bluestore path
{
"/var/lib/ceph/osd/ceph-7//block": {
"osd_uuid": "aa7de90e-0442-4cd9-9927-a17dd666ea74",
"size": 107372085248,
"btime": "2019-07-02 13:56:58.589154",
"description": "main",
"bluefs": "1",
"ceph_fsid": "6effd8df-d109-4ef3-9cfa-c68f9756a54b",
"kv_backend": "rocksdb",
"magic": "ceph osd volume v026",
"mkfs_done": "yes",
"osd_key": "AQCJRhtdZZgTEBAA7G7fzTyj0d2r4RRa/uxaZQ==",
"ready": "ready",
"whoami": "7"
}
}
So the command: ceph-bluestore-tool bluefs-bdev-expand --path
/var/lib/ceph/osd/ceph-7 results in an error I currently cannot
reproduce but the bottom line is that it doesn't expand.
Is bluefs-bdev-expand supported on mimic? Is there a clean way to
expand an OSD ? Right now I'm running the following from ceph-deploy:
# ceph-deploy disk zap vm1-osd1 /dev/vdb
# ceph-deploy osd create vm1-osd1 --data /dev/vdb
The above deletes everything and recreates it which is really not ideal.
Any suggestion?
Thanks in advance.
--
Met vriendelijke groeten,
Valentin Bajrami
Target Holding
