July 2019 - Dev - lists.ceph.io

by Casey Bodley

We've decided to move the Tuesday rgw standup forward 3h45m to better accommodate folks in Asia. This Tuesday standup is likely to include more on Rook integration projects. You can find the updated time on the community calendar at https://ceph.com/contribute/#community-calendar. Casey

4 years, 9 months

1
0
0 0

Re:【In Stock】Discount Party 30% off Jewelry Package & Displays(with pictures)

by Sales70＠toppacking.com

Hi Glad to hear that you're on the market for Jewelry. This is Peter from FANXI. We specialized in jewelry package and displays for 11 years, with the customers of Tiffany,Bvlgari,VanCleef,Boucheron, and hope to find a way to cooperate with you! Catalogue will be sent if needed! Rgds, Peter Whatsapp:+86 15727655534 Wechat:zsp444528275

4 years, 9 months

1
0
0 0

Changing the release cadence

by Sage Weil

Hi everyone, Since luminous, we have had the follow release cadence and policy: - release every 9 months - maintain backports for the last two releases - enable upgrades to move either 1 or 2 releases heads (e.g., luminous -> mimic or nautilus; mimic -> nautilus or octopus; ...) This has mostly worked out well, except that the mimic release received less attention that we wanted due to the fact that multiple downstream Ceph products (from Red Has and SUSE) decided to based their next release on nautilus. Even though upstream every release is an "LTS" release, as a practical matter mimic got less attention than luminous or nautilus. We've had several requests/proposals to shift to a 12 month cadence. This has several advantages: - Stable/conservative clusters only have to be upgraded every 2 years (instead of every 18 months) - Yearly releases are more likely to intersect with downstream distribution release (e.g., Debian). In the past there have been problems where the Ceph releases included in consecutive releases of a distro weren't easily upgradeable. - Vendors that make downstream Ceph distributions/products tend to release yearly. Aligning with those vendors means they are more likely to productize *every* Ceph release. This will help make every Ceph release an "LTS" release (not just in name but also in terms of maintenance attention). So far the balance of opinion seems to favor a shift to a 12 month cycle[1], especially among developers, so it seems pretty likely we'll make that shift. (If you do have strong concerns about such a move, now is the time to raise them.) That brings us to an important decision: what time of year should we release? Once we pick the timing, we'll be releasing at that time *every year* for each release (barring another schedule shift, which we want to avoid), so let's choose carefully! A few options: - November: If we release Octopus 9 months from the Nautilus release (planned for Feb, released in Mar) then we'd target this November. We could shift to a 12 months candence after that. - February: That's 12 months from the Nautilus target. - March: That's 12 months from when Nautilus was *actually* released. November is nice in the sense that we'd wrap things up before the holidays. It's less good in that users may not be inclined to install the new release when many developers will be less available in December. February kind of sucked in that the scramble to get the last few things done happened during the holidays. OTOH, we should be doing what we can to avoid such scrambles, so that might not be something we should factor in. March may be a bit more balanced, with a solid 3 months before when people are productive, and 3 months after before they disappear on holiday to address any post-release issues. People tend to be somewhat less available over the summer months due to holidays etc, so an early or late summer release might also be less than ideal. Thoughts? If we can narrow it down to a few options maybe we could do a poll to gauge user preferences. Thanks! sage [1] https://twitter.com/larsmb/status/1130010208971952129

4 years, 9 months

14
20
0 0

07/20/2019 perf meeting is on!

by Mark Nelson

Hi Folks, Perf meeting is on in ~10 minutes! Today's agenda: RocksDB OMAP performance work, Adam's sharding work, and improving OpTracker performance. Please feel free to add your own topic! Etherpad: https://pad.ceph.com/p/performance_weekly Bluejeans: https://bluejeans.com/908675367 Thanks, Mark

4 years, 9 months

1
0
0 0

Static Analysis

by Brad Hubbard

Latest static analyser results are up on http://people.redhat.com/bhubbard/ Weekly Fedora Copr builds are at https://copr.fedorainfracloud.org/coprs/badone/ceph-weeklies/ -- Cheers, Brad

4 years, 9 months

1
0
0 0

New ceph-volume lead

by Alfredo Deza

Hi all, As Andrew Schoen and I move on to other projects, we've asked Jan Fajerski to lead the ceph-volume project so that it gets the attention it needs for all the new development that is going on. Jan has already been doing lots of work and knows the tool very well, and we are sure it will help backports, tests, and new code reviewed more promptly. Andrew and I will still be around helping the transition and fully available to advise on ceph-volume's direction when needed. Thanks, Alfredo

4 years, 9 months

1
0
0 0

14.2.2 QE Nautilus validation status

by Yuri Weinstein

Details of this release summarized here: http://tracker.ceph.com/issues/40404#note-5 rados - PASSED rgw - Casey pls review/approve rbd - Jason pls review/approve krbd - Ilya pls review/approve fs - Patrick pls review/approve kcephfs - Patrick pls review/approve multimds - Patrick pls review/approve ceph-deploy - FAILED Sage FYI, decision needed! upgrade/client-upgrade-hammer (nautilus) - PASSED upgrade/client-upgrade-jewel (nautilus) - PASSED upgrade/client-upgrade-mimic (nautilus) - PASSED upgrade/luminous-p2p - in progress, Casey is fixing powercycle - PASSED ceph-ansible - in progress, Brad is fixing upgrade/luminous-x (nautilus) - in progress, Casey is fixing upgrade/mimic-x (nautilus) - in progress, Casey is fixing ceph-volume - in progress (please speak up if something is missing) Thx YuriW

4 years, 9 months

9
18
0 0

s/Mutex/ceph::mutex/ and Mutex::is_locked_by_me()

by kefu chai

hi Patrick and list, i am trying replace Mutex with ceph::mutex in Ceph. the goal is to deprecate and then remove Mutex and Cond from our project. as we have already ceph::mutex and ceph::condition_variable. it's confusing and, in the long run, i think, it will hurt us as a technical debt. most of the refactory work is quite straightforward, and we can always replace Mutex::is_locked_by_me() with ceph_mutex_is_locked_by_me(). this macro will be expanded to `true` in release build. as we think it will be used only by `ceph_assert()` and `assert()`. but i realized that we are also using Mutex::is_locked_by_me() in functional code which won't be optimised out. for instance, in MDSRank::MDSRank() we check "mds_lock.is_locked_by_me()", if it's true, we just `handle_write_error(r)` without acquiring the lock, otherwise, we will call this function within `mds_lock`. the same applies to `MDSDaemon::handle_conf_change()`. so i am wondering if it's okay to change `mds_lock` to a recursive lock, so we don't need to query this information from the mutex. what do you think? -- Regards Kefu Chai

4 years, 9 months

3
6
0 0

sandbox question

by solarflow99

Hi, I'm trying to bring up a sandbox ceph environment based on the guide, and I am running into a problem with the ceph-ansible provisioning, it keeps complaining about netaddr even though I installed python2-netaddr. fatal: [client0]: FAILED! => msg: The ipwrap filter requires python's netaddr be installed on the ansible controller NO MORE HOSTS LEFT ************************************************************* PLAY RECAP ********************************************************************* client0 : ok=22 changed=0 unreachable=0 failed=1 skipped=27 rescued=0 ignored=0 mon0 : ok=25 changed=1 unreachable=0 failed=1 skipped=27 rescued=0 ignored=0 osd0 : ok=25 changed=0 unreachable=0 failed=1 skipped=24 rescued=0 ignored=0 osd1 : ok=25 changed=0 unreachable=0 failed=1 skipped=24 rescued=0 ignored=0 osd2 : ok=25 changed=0 unreachable=0 failed=1 skipped=24 rescued=0 ignored=0 # cat /etc/redhat-release Fedora release 30 (Thirty) # rpm -qa | grep netaddr python2-netaddr-0.7.19-14.fc30.noarch # ansible --version ansible 2.8.1 config file = /root/ceph-sandbox/ceph-ansible/ansible.cfg configured module search path = ['/root/ceph-sandbox/ceph-ansible/library'] ansible python module location = /usr/lib/python3.7/site-packages/ansible executable location = /usr/bin/ansible python version = 3.7.3 (default, May 11 2019, 00:38:04) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] # python --version Python 2.7.16 # vagrant --version Vagrant 2.2.4 # git branch master * stable-4.0

4 years, 9 months

2
2
0 0

subscribe ceph-devel

by 刘军

4 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

Dev July 2019