Pacific release candidate v16.1.0 is out
There are just a couple remaining issues before the final release. Please test it out and report any bugs. The full release notes are in progress here [0]. Notable Changes --------------- * New ``bluestore_rocksdb_options_annex`` config parameter. Complements ``bluestore_rocksdb_options`` and allows setting rocksdb options without repeating the existing defaults. * The cephfs addes two new CDentry tags, 'I' --> 'i' and 'L' --> 'l', and on-RADOS metadata is no longer backwards compatible after upgraded to Pacific or a later release. * $pid expansion in config paths like ``admin_socket`` will now properly expand to the daemon pid for commands like ``ceph-mds`` or ``ceph-osd``. Previously only ``ceph-fuse``/``rbd-nbd`` expanded ``$pid`` with the actual daemon pid. * The allowable options for some ``radosgw-admin`` commands have been changed. * ``mdlog-list``, ``datalog-list``, ``sync-error-list`` no longer accepts start and end dates, but does accept a single optional start marker. * ``mdlog-trim``, ``datalog-trim``, ``sync-error-trim`` only accept a single marker giving the end of the trimmed range. * Similarly the date ranges and marker ranges have been removed on the RESTful DATALog and MDLog list and trim operations. * ceph-volume: The ``lvm batch`` subcommand received a major rewrite. This closed a number of bugs and improves usability in terms of size specification and calculation, as well as idempotency behaviour and disk replacement process. Please refer to https://docs.ceph.com/en/latest/ceph-volume/lvm/batch/ for more detailed information. * Configuration variables for permitted scrub times have changed. The legal values for ``osd_scrub_begin_hour`` and ``osd_scrub_end_hour`` are 0 - 23. The use of 24 is now illegal. Specifying ``0`` for both values causes every hour to be allowed. The legal vaues for ``osd_scrub_begin_week_day`` and ``osd_scrub_end_week_day`` are 0 - 6. The use of 7 is now illegal. Specifying ``0`` for both values causes every day of the week to be allowed. * Multiple file systems in a single Ceph cluster is now stable. New Ceph clusters enable support for multiple file systems by default. Existing clusters must still set the "enable_multiple" flag on the fs. Please see the CephFS documentation for more information. * volume/nfs: Recently "ganesha-" prefix from cluster id and nfs-ganesha common config object was removed, to ensure consistent namespace across different orchestrator backends. Please delete any existing nfs-ganesha clusters prior to upgrading and redeploy new clusters after upgrading to Pacific. * A new health check, DAEMON_OLD_VERSION, will warn if different versions of Ceph are running on daemons. It will generate a health error if multiple versions are detected. This condition must exist for over mon_warn_older_version_delay (set to 1 week by default) in order for the health condition to be triggered. This allows most upgrades to proceed without falsely seeing the warning. If upgrade is paused for an extended time period, health mute can be used like this "ceph health mute DAEMON_OLD_VERSION --sticky". In this case after upgrade has finished use "ceph health unmute DAEMON_OLD_VERSION". * MGR: progress module can now be turned on/off, using the commands: ``ceph progress on`` and ``ceph progress off``. * An AWS-compliant API: "GetTopicAttributes" was added to replace the existing "GetTopic" API. The new API should be used to fetch information about topics used for bucket notifications. * librbd: The shared, read-only parent cache's config option ``immutable_object_cache_watermark`` now has been updated to property reflect the upper cache utilization before space is reclaimed. The default ``immutable_object_cache_watermark`` now is ``0.9``. If the capacity reaches 90% the daemon will delete cold cache. * OSD: the option ``osd_fast_shutdown_notify_mon`` has been introduced to allow the OSD to notify the monitor it is shutting down even if ``osd_fast_shutdown`` is enabled. This helps with the monitor logs on larger clusters, that may get many 'osd.X reported immediately failed by osd.Y' messages, and confuse tools. [0] https://github.com/ceph/ceph/pull/40265
On Wednesday, March 24, 2021 7:37:22 PM EDT Josh Durgin wrote:
There are just a couple remaining issues before the final release. Please test it out and report any bugs.
I'm not sure where this RC can be found. I looked at https://github.com/ceph/ ceph/releases but the v16.1.0 tag shows up as from Jan. So I'm not sure if I am looking in the correct place. I haven't tried this before so I may be looking in the wrong place. Context: I wanted to retest a go-ceph test case that is currently failing on the version of pacific available from ceph container (as of last week) [1]. If that doesn't work I wanted to try and apply a patch from a possibly related issue. But since I haven't compiled ceph before I figured I start with the RC first before trying out patches. [1] - https://tracker.ceph.com/issues/49873 Thanks.
The full release notes are in progress here [0].
Notable Changes ---------------
* New ``bluestore_rocksdb_options_annex`` config parameter. Complements ``bluestore_rocksdb_options`` and allows setting rocksdb options without repeating the existing defaults.
* The cephfs addes two new CDentry tags, 'I' --> 'i' and 'L' --> 'l', and on-RADOS metadata is no longer backwards compatible after upgraded to Pacific or a later release.
* $pid expansion in config paths like ``admin_socket`` will now properly expand to the daemon pid for commands like ``ceph-mds`` or ``ceph-osd``. Previously only ``ceph-fuse``/``rbd-nbd`` expanded ``$pid`` with the actual daemon pid.
* The allowable options for some ``radosgw-admin`` commands have been changed.
* ``mdlog-list``, ``datalog-list``, ``sync-error-list`` no longer accepts start and end dates, but does accept a single optional start marker. * ``mdlog-trim``, ``datalog-trim``, ``sync-error-trim`` only accept a single marker giving the end of the trimmed range. * Similarly the date ranges and marker ranges have been removed on the RESTful DATALog and MDLog list and trim operations.
* ceph-volume: The ``lvm batch`` subcommand received a major rewrite. This closed a number of bugs and improves usability in terms of size specification and calculation, as well as idempotency behaviour and disk replacement process. Please refer to https://docs.ceph.com/en/latest/ceph-volume/lvm/batch/ for more detailed information.
* Configuration variables for permitted scrub times have changed. The legal values for ``osd_scrub_begin_hour`` and ``osd_scrub_end_hour`` are 0 - 23. The use of 24 is now illegal. Specifying ``0`` for both values causes every hour to be allowed. The legal vaues for ``osd_scrub_begin_week_day`` and ``osd_scrub_end_week_day`` are 0 - 6. The use of 7 is now illegal. Specifying ``0`` for both values causes every day of the week to be allowed.
* Multiple file systems in a single Ceph cluster is now stable. New Ceph clusters enable support for multiple file systems by default. Existing clusters must still set the "enable_multiple" flag on the fs. Please see the CephFS documentation for more information.
* volume/nfs: Recently "ganesha-" prefix from cluster id and nfs-ganesha common config object was removed, to ensure consistent namespace across different orchestrator backends. Please delete any existing nfs-ganesha clusters prior to upgrading and redeploy new clusters after upgrading to Pacific.
* A new health check, DAEMON_OLD_VERSION, will warn if different versions of Ceph are running on daemons. It will generate a health error if multiple versions are detected. This condition must exist for over mon_warn_older_version_delay (set to 1 week by default) in order for the health condition to be triggered. This allows most upgrades to proceed without falsely seeing the warning. If upgrade is paused for an extended time period, health mute can be used like this "ceph health mute DAEMON_OLD_VERSION --sticky". In this case after upgrade has finished use "ceph health unmute DAEMON_OLD_VERSION".
* MGR: progress module can now be turned on/off, using the commands: ``ceph progress on`` and ``ceph progress off``. * An AWS-compliant API: "GetTopicAttributes" was added to replace the existing "GetTopic" API. The new API should be used to fetch information about topics used for bucket notifications.
* librbd: The shared, read-only parent cache's config option ``immutable_object_cache_watermark`` now has been updated to property reflect the upper cache utilization before space is reclaimed. The default ``immutable_object_cache_watermark`` now is ``0.9``. If the capacity reaches 90% the daemon will delete cold cache.
* OSD: the option ``osd_fast_shutdown_notify_mon`` has been introduced to allow the OSD to notify the monitor it is shutting down even if ``osd_fast_shutdown`` is enabled. This helps with the monitor logs on larger clusters, that may get many 'osd.X reported immediately failed by osd.Y' messages, and confuse tools.
[0] https://github.com/ceph/ceph/pull/40265 _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- --John M.
If you're compiling you can use the pacific branch. The latest pacific container would be based on the pacific branch, and include the RC and additional fixes since then. The RC packages are on https://download.ceph.com in the usual places, e.g.: https://download.ceph.com/debian-16.1.0/ https://download.ceph.com/rpm-16.1.0/ Using these repos is described here: https://docs.ceph.com/en/latest/install/get-packages/ Josh On 3/25/21 10:57 AM, John Mulligan wrote:
On Wednesday, March 24, 2021 7:37:22 PM EDT Josh Durgin wrote:
There are just a couple remaining issues before the final release. Please test it out and report any bugs.
I'm not sure where this RC can be found. I looked at https://github.com/ceph/ ceph/releases but the v16.1.0 tag shows up as from Jan. So I'm not sure if I am looking in the correct place. I haven't tried this before so I may be looking in the wrong place.
Context: I wanted to retest a go-ceph test case that is currently failing on the version of pacific available from ceph container (as of last week) [1]. If that doesn't work I wanted to try and apply a patch from a possibly related issue. But since I haven't compiled ceph before I figured I start with the RC first before trying out patches.
[1] - https://tracker.ceph.com/issues/49873
Thanks.
The full release notes are in progress here [0].
Notable Changes ---------------
* New ``bluestore_rocksdb_options_annex`` config parameter. Complements ``bluestore_rocksdb_options`` and allows setting rocksdb options without repeating the existing defaults.
* The cephfs addes two new CDentry tags, 'I' --> 'i' and 'L' --> 'l', and on-RADOS metadata is no longer backwards compatible after upgraded to Pacific or a later release.
* $pid expansion in config paths like ``admin_socket`` will now properly expand to the daemon pid for commands like ``ceph-mds`` or ``ceph-osd``. Previously only ``ceph-fuse``/``rbd-nbd`` expanded ``$pid`` with the actual daemon pid.
* The allowable options for some ``radosgw-admin`` commands have been changed.
* ``mdlog-list``, ``datalog-list``, ``sync-error-list`` no longer accepts start and end dates, but does accept a single optional start marker. * ``mdlog-trim``, ``datalog-trim``, ``sync-error-trim`` only accept a single marker giving the end of the trimmed range. * Similarly the date ranges and marker ranges have been removed on the RESTful DATALog and MDLog list and trim operations.
* ceph-volume: The ``lvm batch`` subcommand received a major rewrite. This closed a number of bugs and improves usability in terms of size specification and calculation, as well as idempotency behaviour and disk replacement process. Please refer to https://docs.ceph.com/en/latest/ceph-volume/lvm/batch/ for more detailed information.
* Configuration variables for permitted scrub times have changed. The legal values for ``osd_scrub_begin_hour`` and ``osd_scrub_end_hour`` are 0 - 23. The use of 24 is now illegal. Specifying ``0`` for both values causes every hour to be allowed. The legal vaues for ``osd_scrub_begin_week_day`` and ``osd_scrub_end_week_day`` are 0 - 6. The use of 7 is now illegal. Specifying ``0`` for both values causes every day of the week to be allowed.
* Multiple file systems in a single Ceph cluster is now stable. New Ceph clusters enable support for multiple file systems by default. Existing clusters must still set the "enable_multiple" flag on the fs. Please see the CephFS documentation for more information.
* volume/nfs: Recently "ganesha-" prefix from cluster id and nfs-ganesha common config object was removed, to ensure consistent namespace across different orchestrator backends. Please delete any existing nfs-ganesha clusters prior to upgrading and redeploy new clusters after upgrading to Pacific.
* A new health check, DAEMON_OLD_VERSION, will warn if different versions of Ceph are running on daemons. It will generate a health error if multiple versions are detected. This condition must exist for over mon_warn_older_version_delay (set to 1 week by default) in order for the health condition to be triggered. This allows most upgrades to proceed without falsely seeing the warning. If upgrade is paused for an extended time period, health mute can be used like this "ceph health mute DAEMON_OLD_VERSION --sticky". In this case after upgrade has finished use "ceph health unmute DAEMON_OLD_VERSION".
* MGR: progress module can now be turned on/off, using the commands: ``ceph progress on`` and ``ceph progress off``. * An AWS-compliant API: "GetTopicAttributes" was added to replace the existing "GetTopic" API. The new API should be used to fetch information about topics used for bucket notifications.
* librbd: The shared, read-only parent cache's config option ``immutable_object_cache_watermark`` now has been updated to property reflect the upper cache utilization before space is reclaimed. The default ``immutable_object_cache_watermark`` now is ``0.9``. If the capacity reaches 90% the daemon will delete cold cache.
* OSD: the option ``osd_fast_shutdown_notify_mon`` has been introduced to allow the OSD to notify the monitor it is shutting down even if ``osd_fast_shutdown`` is enabled. This helps with the monitor logs on larger clusters, that may get many 'osd.X reported immediately failed by osd.Y' messages, and confuse tools.
[0] https://github.com/ceph/ceph/pull/40265 _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On Thu, Mar 25, 2021 at 3:07 PM Josh Durgin <jdurgin@redhat.com> wrote:
If you're compiling you can use the pacific branch.
The latest pacific container would be based on the pacific branch, and include the RC and additional fixes since then.
The RC packages are on https://download.ceph.com in the usual places, e.g.:
https://download.ceph.com/debian-16.1.0/ https://download.ceph.com/rpm-16.1.0/
Hi, That's the packages, what about "the usual" source tar.gz files, e.g. https://download.ceph.com/tarballs/ceph-16.1.0.tar.gz and https://download.ceph.com/tarballs/ceph_16.1.0.orig.tar.gz? I never did get a satisfactory answer about why the v16.1.0 tag was made back in January without a matching .../tarballs/ceph-16.1.0.tar.gz. I kept getting long winded explanations — digressions — about "the release," (meaning the GA I guess?) which I wasn't asking about. AFAICT since at least jewel, there's been a matching tar.gz for every vX.1.z tag (and every vX.2.z tag too, but let's not muddy the waters.) And what tag is it now that corresponds to the ceph-16.1.0 packages? IMO it kinda violates POLA that the v16.1.0 tag has no relationship whatsoever to the RC. (It would also violate POLA, IMO, to move the tag. And I've been assured that the tag won't be moved, so that much at least is good.) And yes, I can simply extract the tar.gz from the src.rpm. That's beside the point. Regards, -- Kaleb
I don't know anything about the .tar.gz, but I can speak to the tags... On Thu, Mar 25, 2021 at 2:38 PM Kaleb Keithley <kkeithle@redhat.com> wrote:
I never did get a satisfactory answer about why the v16.1.0 tag was made back in January without a matching .../tarballs/ceph-16.1.0.tar.gz. I kept getting long winded explanations — digressions — about "the release," (meaning the GA I guess?) which I wasn't asking about.
I created the v17.0.0 and v16.1.0 tags because we branched off development for pacific stable, and I needed the versions to reflect that. The version in the pacific branched needed to be < than the master branch version for upgrade to behave, the major portion (16, 17) of the version needed to agree with the ceph_release file, and so on. Those tags didn't correspond to any "release" per se.
AFAICT since at least jewel, there's been a matching tar.gz for every vX.1.z tag (and every vX.2.z tag too, but let's not muddy the waters.)
And what tag is it now that corresponds to the ceph-16.1.0 packages? IMO it kinda violates POLA that the v16.1.0 tag has no relationship whatsoever to the RC.
This was just a bit of a mix-up because of the above. When David did the pacific build off of the branch tip last week he used 16.1.0 because he didn't realize that tag already existed, and for an rc it didn't seem worth repeating the build. HTH! s
On Thu, Mar 25, 2021 at 2:55 PM Sage Weil <sage@newdream.net> wrote:
This was just a bit of a mix-up because of the above. When David did the pacific build off of the branch tip last week he used 16.1.0 because he didn't realize that tag already existed, and for an rc it didn't seem worth repeating the build.
For the record, users should not expect the https://github.com/ceph/ceph/releases/tag/v16.1.0 to move, right? It would be nice to release v16.1.1 to clear this up. - Ken
If 16.2.0 is as close as Sage says it is, I'm not sure a 16.1.1 is really worth doing at this point. And I was assured some time back that the tag will not move. On Mon, Mar 29, 2021 at 10:30 AM Ken Dreyer <kdreyer@redhat.com> wrote:
On Thu, Mar 25, 2021 at 2:55 PM Sage Weil <sage@newdream.net> wrote:
This was just a bit of a mix-up because of the above. When David did the pacific build off of the branch tip last week he used 16.1.0 because he didn't realize that tag already existed, and for an rc it didn't seem worth repeating the build.
For the record, users should not expect the https://github.com/ceph/ceph/releases/tag/v16.1.0 to move, right?
It would be nice to release v16.1.1 to clear this up.
- Ken
participants (5)
-
John Mulligan
-
Josh Durgin
-
Kaleb Keithley
-
Ken Dreyer
-
Sage Weil