hey Gal and Eric,
in today's standup, we discussed the version of our apache arrow
submodule. it's currently pinned at 6.0.1, which was tagged in nov.
2021. the centos9 builds are using the system package
libarrow-devel-9.0.0. arrow's upstream recently tagged an 11.0.0
release
as far as i know, there still aren't any system packages for ubuntu,
so we're likely to be stuck with the submodule for quite a while. how
do guys want to handle these updates? is it worth trying to update
before the reef release?
hi Ernesto and lists,
> [1] https://github.com/ceph/ceph/pull/47501
are we planning to backport this to quincy so we can support centos 9
there? enabling that upgrade path on centos 9 was one of the
conditions for dropping centos 8 support in reef, which i'm still keen
to do
if not, can we find another resolution to
https://tracker.ceph.com/issues/58832? as i understand it, all of
those python packages exist in centos 8. do we know why they were
dropped for centos 9? have we looked into making those available in
epel? (cc Ken and Kaleb)
On Fri, Sep 2, 2022 at 12:01 PM Ernesto Puerta <epuertat(a)redhat.com> wrote:
>
> Hi Kevin,
>
>>
>> Isn't this one of the reasons containers were pushed, so that the packaging isn't as big a deal?
>
>
> Yes, but the Ceph community has a strong commitment to provide distro packages for those users who are not interested in moving to containers.
>
>> Is it the continued push to support lots of distros without using containers that is the problem?
>
>
> If not a problem, it definitely makes it more challenging. Compiled components often sort this out by statically linking deps whose packages are not widely available in distros. The approach we're proposing here would be the closest equivalent to static linking for interpreted code (bundling).
>
> Thanks for sharing your questions!
>
> Kind regards,
> Ernesto
> _______________________________________________
> Dev mailing list -- dev(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io
Details of this release are summarized here:
https://tracker.ceph.com/issues/59070#note-1
Release Notes - TBD
The reruns were in the queue for 4 days because of some slowness issues.
The core team (Neha, Radek, Laura, and others) are trying to narrow
down the root cause.
Seeking approvals/reviews for:
rados - Neha, Radek, Travis, Ernesto, Adam King (we still have to test
and merge at least one PR https://github.com/ceph/ceph/pull/50575 for
the core)
rgw - Casey
fs - Venky (the fs suite has an unusually high amount of failed jobs,
any reason to suspect it in the observed slowness?)
orch - Adam King
rbd - Ilya
krbd - Ilya
upgrade/octopus-x - Laura is looking into failures
upgrade/pacific-x - Laura is looking into failures
upgrade/quincy-p2p - Laura is looking into failures
client-upgrade-octopus-quincy-quincy - missing packages, Adam Kraitman
is looking into it
powercycle - Brad
ceph-volume - needs a rerun on merged
https://github.com/ceph/ceph-ansible/pull/7409
Please reply to this email with approval and/or trackers of known
issues/PRs to address them.
Also, share any findings or hypnosis about the slowness in the
execution of the suite.
Josh, Neha - gibba and LRC upgrades pending major suites approvals.
RC release - pending major suites approvals.
Thx
YuriW
the rgw suite just started hitting a tcmalloc crash on main against
ubuntu 20.04: https://tracker.ceph.com/issues/59269
> src/tcmalloc.cc:332] Attempt to free invalid pointer 0x55e8173eebd0
this happens during startup of one of our librgw_file test cases
https://tracker.ceph.com/issues/58219 tracks a similar crash from the
fs suite in december, which apparently went away after reverting a
change to ceph-dencoder's linkage, but it doesn't sound like we ever
found the root cause
is this crash showing up anywhere else? has anything changed with
respect to tcmalloc versions or linkage recently?
Hello,
On April 1, 2023, the Ceph GitHub organization will start requiring
two-factor authentication for all accounts (both members and outside
collaborators). Any account that doesn't have two-factor
authentication enabled on that date will be automatically removed from
the organization. Disabling two-factor authentication on the account
after that date would also remove it from the organization.
If you don't have two-factor authentication enabled on your account
already (some core developers still don't!), follow instructions at [1]
to set it up. See [2] for a good explanation of why it matters.
[1] https://docs.github.com/en/authentication/securing-your-account-with-two-fa…
[2] https://github.blog/2022-05-04-software-security-starts-with-the-developer-…
Thanks,
Ilya
Hi Folks,
I will be taking a very much needed holiday starting tomorrow and thus
will not be running the next two performance meetings. Josh has kindly
accepted the responsibility for running them however!
If there are problems with the Jitsi transition I'm not responsible. ;)
Etherpad:
https://pad.ceph.com/p/performance_weekly
Bluejeans (Assuming it's not Jitsi!):
https://bluejeans.com/908675367
Mark
Hi All,
We are looking for inputs on a new feature to be implemented to move clog
messages storage from monstore db, refer trello card [1] for more details
around this topic.
Currently, every clog message goes to monstore db as well as debug/warning
messages generates clog messages 1000s of times per seconds which leads to
monstore db growing at an exponential rate in a catastrophic failure
situation.
The primary use cases for the logm entries in monstore db are :
- For "ceph log last" commands to get historical clog entries
- Ceph dashboard (mgr is subscriber of log-info which propagate clog to
dashboard module)
@Patrick Donnelly <pdonnell(a)redhat.com> suggested a viable solution to move
the cluster log storage to a new mgr module which handles the "ceph log
last" command. The clog data can be stored in the .mgr pool via
libcephsqlite.
Alternatively, if we donot want to get rid of logm storage from monstore db
then the other solutions would be :
- Stop writing logm entries to mon db if there are excessive entries
getting generated
- Filter out clog DBG entries and only log WRN/INF/ERR entries.
Looking forward to additional perspectives arounds this topic. Feel free to
add your inputs to trello card [1] or reply to this email-thread.
[1]
https://trello.com/c/oCGGFfTs/822-better-handling-of-cluster-log-messages-f…
Regards,
Prashant