Re: [ceph-users] v11.1.0 kraken candidate released
On 02/16/2017 09:47 AM, John Spray wrote: > On Thu, Feb 16, 2017 at 8:37 AM, Dietmar Rieder > wrote: >> Hi, >> >> On 12/13/2016 12:35 PM, John Spray wrote: >>> On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder >>> wrote: Hi, this is good news! Thanks. As far as I see the RBD supports (experimentally) now EC data pools. Is this true also for CephFS? It is not stated in the announce, so I wonder if and when EC pools are planned to be supported by CephFS. >>> >>> Nobody has worked on this so far. For EC data pools, it should mainly >>> be a case of modifying the pool validation in MDSMonitor that >>> currently prevents assigning an EC pool. I strongly suspect we'll get >>> around to this before Luminous. >>> >> >> since v12.0.0 Luminous (dev) released is now released, I just wanted to >> ask if there was some work done in order to enable cephfs data pools on EC? > > To clarify, the luminous release I was talking about was the stable > one (what will eventually be 12.2.0 later in the year). John, thanks for clarifying. Dietmar -- _ D i e t m a r R i e d e r, Mag.Dr. Innsbruck Medical University Biocenter - Division for Bioinformatics Innrain 80, 6020 Innsbruck Phone: +43 512 9003 71402 Fax: +43 512 9003 73100 Email: dietmar.rie...@i-med.ac.at Web: http://www.icbi.at signature.asc Description: OpenPGP digital signature ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
On Thu, Feb 16, 2017 at 8:37 AM, Dietmar Rieder wrote: > Hi, > > On 12/13/2016 12:35 PM, John Spray wrote: >> On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder >> wrote: >>> Hi, >>> >>> this is good news! Thanks. >>> >>> As far as I see the RBD supports (experimentally) now EC data pools. Is >>> this true also for CephFS? It is not stated in the announce, so I wonder >>> if and when EC pools are planned to be supported by CephFS. >> >> Nobody has worked on this so far. For EC data pools, it should mainly >> be a case of modifying the pool validation in MDSMonitor that >> currently prevents assigning an EC pool. I strongly suspect we'll get >> around to this before Luminous. >> > > since v12.0.0 Luminous (dev) released is now released, I just wanted to > ask if there was some work done in order to enable cephfs data pools on EC? To clarify, the luminous release I was talking about was the stable one (what will eventually be 12.2.0 later in the year). Cheers, John > Thanks > Dietmar > > -- > _ > D i e t m a r R i e d e r, Mag.Dr. > Innsbruck Medical University > Biocenter - Division for Bioinformatics > Innrain 80, 6020 Innsbruck > Phone: +43 512 9003 71402 > Fax: +43 512 9003 73100 > Email: dietmar.rie...@i-med.ac.at > Web: http://www.icbi.at > > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
Hi, On 12/13/2016 12:35 PM, John Spray wrote: > On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder > wrote: >> Hi, >> >> this is good news! Thanks. >> >> As far as I see the RBD supports (experimentally) now EC data pools. Is >> this true also for CephFS? It is not stated in the announce, so I wonder >> if and when EC pools are planned to be supported by CephFS. > > Nobody has worked on this so far. For EC data pools, it should mainly > be a case of modifying the pool validation in MDSMonitor that > currently prevents assigning an EC pool. I strongly suspect we'll get > around to this before Luminous. > since v12.0.0 Luminous (dev) released is now released, I just wanted to ask if there was some work done in order to enable cephfs data pools on EC? Thanks Dietmar -- _ D i e t m a r R i e d e r, Mag.Dr. Innsbruck Medical University Biocenter - Division for Bioinformatics Innrain 80, 6020 Innsbruck Phone: +43 512 9003 71402 Fax: +43 512 9003 73100 Email: dietmar.rie...@i-med.ac.at Web: http://www.icbi.at signature.asc Description: OpenPGP digital signature ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
OK, thanks for the update Greg! - Darrell ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
On Tue, Dec 13, 2016 at 4:34 PM, Darrell Enns wrote: > Are CephFS snapshots still considered unstable/experimental in Kraken? Sadly, yes. I had a solution but they didn't account for hard links. When we decided we wanted to support those instead of ignoring them or trying to set up boundary regions which disallow one or the other, I had to go back to the drawing board. Working on a design but it's taking a back burner to other things like stabilizing multi-MDS features. :) -Greg ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
Are CephFS snapshots still considered unstable/experimental in Kraken? ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] v11.1.0 kraken candidate released
On Tue, Dec 13, 2016 at 12:18 PM, Dietmar Rieder wrote: > Hi John, > > Thanks for your answer. > The mentioned modification of the pool validation would than allow for > CephFS having the data pools on EC while keeping the metadata on a > replicated pool, right? I would expect so. John > > Dietmar > > On 12/13/2016 12:35 PM, John Spray wrote: >> On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder >> wrote: >>> Hi, >>> >>> this is good news! Thanks. >>> >>> As far as I see the RBD supports (experimentally) now EC data pools. Is >>> this true also for CephFS? It is not stated in the announce, so I wonder >>> if and when EC pools are planned to be supported by CephFS. >> >> Nobody has worked on this so far. For EC data pools, it should mainly >> be a case of modifying the pool validation in MDSMonitor that >> currently prevents assigning an EC pool. I strongly suspect we'll get >> around to this before Luminous. >> >> John >> >>> ~regards >>> Dietmar >>> >>> On 12/13/2016 03:28 AM, Abhishek L wrote: Hi everyone, This is the first release candidate for Kraken, the next stable release series. There have been major changes from jewel with many features being added. Please note the upgrade process from jewel, before upgrading. Major Changes from Jewel - *RADOS*: * The new *BlueStore* backend now has a stable disk format and is passing our failure and stress testing. Although the backend is still flagged as experimental, we encourage users to try it out for non-production clusters and non-critical data sets. * RADOS now has experimental support for *overwrites on erasure-coded* pools. Because the disk format and implementation are not yet finalized, there is a special pool option that must be enabled to test the new feature. Enabling this option on a cluster will permanently bar that cluster from being upgraded to future versions. * We now default to the AsyncMessenger (``ms type = async``) instead of the legacy SimpleMessenger. The most noticeable difference is that we now use a fixed sized thread pool for network connections (instead of two threads per socket with SimpleMessenger). * Some OSD failures are now detected almost immediately, whereas previously the heartbeat timeout (which defaults to 20 seconds) had to expire. This prevents IO from blocking for an extended period for failures where the host remains up but the ceph-osd process is no longer running. * There is a new ``ceph-mgr`` daemon. It is currently collocated with the monitors by default, and is not yet used for much, but the basic infrastructure is now in place. * The size of encoded OSDMaps has been reduced. * The OSDs now quiesce scrubbing when recovery or rebalancing is in progress. - *RGW*: * RGW now supports a new zone type that can be used for metadata indexing via Elasticseasrch. * RGW now supports the S3 multipart object copy-part API. * It is possible now to reshard an existing bucket. Note that bucket resharding currently requires that all IO (especially writes) to the specific bucket is quiesced. * RGW now supports data compression for objects. * Civetweb version has been upgraded to 1.8 * The Swift static website API is now supported (S3 support has been added previously). * S3 bucket lifecycle API has been added. Note that currently it only supports object expiration. * Support for custom search filters has been added to the LDAP auth implementation. * Support for NFS version 3 has been added to the RGW NFS gateway. * A Python binding has been created for librgw. - *RBD*: * RBD now supports images stored in an *erasure-coded* RADOS pool using the new (experimental) overwrite support. Images must be created using the new rbd CLI "--data-pool " option to specify the EC pool where the backing data objects are stored. Attempting to create an image directly on an EC pool will not be successful since the image's backing metadata is only supported on a replicated pool. * The rbd-mirror daemon now supports replicating dynamic image feature updates and image metadata key/value pairs from the primary image to the non-primary image. * The number of image snapshots can be optionally restricted to a configurable maximum. * The rbd Python API now supports asynchronous IO operations. - *CephFS*: * libcephfs function definitions have been changed to enable proper uid/gid control. The library version has been increased to reflect the interface
Re: [ceph-users] v11.1.0 kraken candidate released
Hi John, Thanks for your answer. The mentioned modification of the pool validation would than allow for CephFS having the data pools on EC while keeping the metadata on a replicated pool, right? Dietmar On 12/13/2016 12:35 PM, John Spray wrote: > On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder > wrote: >> Hi, >> >> this is good news! Thanks. >> >> As far as I see the RBD supports (experimentally) now EC data pools. Is >> this true also for CephFS? It is not stated in the announce, so I wonder >> if and when EC pools are planned to be supported by CephFS. > > Nobody has worked on this so far. For EC data pools, it should mainly > be a case of modifying the pool validation in MDSMonitor that > currently prevents assigning an EC pool. I strongly suspect we'll get > around to this before Luminous. > > John > >> ~regards >> Dietmar >> >> On 12/13/2016 03:28 AM, Abhishek L wrote: >>> Hi everyone, >>> >>> This is the first release candidate for Kraken, the next stable >>> release series. There have been major changes from jewel with many >>> features being added. Please note the upgrade process from jewel, >>> before upgrading. >>> >>> Major Changes from Jewel >>> >>> >>> - *RADOS*: >>> >>> * The new *BlueStore* backend now has a stable disk format and is >>> passing our failure and stress testing. Although the backend is >>> still flagged as experimental, we encourage users to try it out >>> for non-production clusters and non-critical data sets. >>> * RADOS now has experimental support for *overwrites on >>> erasure-coded* pools. Because the disk format and implementation >>> are not yet finalized, there is a special pool option that must be >>> enabled to test the new feature. Enabling this option on a cluster >>> will permanently bar that cluster from being upgraded to future >>> versions. >>> * We now default to the AsyncMessenger (``ms type = async``) instead >>> of the legacy SimpleMessenger. The most noticeable difference is >>> that we now use a fixed sized thread pool for network connections >>> (instead of two threads per socket with SimpleMessenger). >>> * Some OSD failures are now detected almost immediately, whereas >>> previously the heartbeat timeout (which defaults to 20 seconds) >>> had to expire. This prevents IO from blocking for an extended >>> period for failures where the host remains up but the ceph-osd >>> process is no longer running. >>> * There is a new ``ceph-mgr`` daemon. It is currently collocated with >>> the monitors by default, and is not yet used for much, but the basic >>> infrastructure is now in place. >>> * The size of encoded OSDMaps has been reduced. >>> * The OSDs now quiesce scrubbing when recovery or rebalancing is in >>> progress. >>> >>> - *RGW*: >>> >>> * RGW now supports a new zone type that can be used for metadata indexing >>> via Elasticseasrch. >>> * RGW now supports the S3 multipart object copy-part API. >>> * It is possible now to reshard an existing bucket. Note that bucket >>> resharding currently requires that all IO (especially writes) to >>> the specific bucket is quiesced. >>> * RGW now supports data compression for objects. >>> * Civetweb version has been upgraded to 1.8 >>> * The Swift static website API is now supported (S3 support has been added >>> previously). >>> * S3 bucket lifecycle API has been added. Note that currently it only >>> supports >>> object expiration. >>> * Support for custom search filters has been added to the LDAP auth >>> implementation. >>> * Support for NFS version 3 has been added to the RGW NFS gateway. >>> * A Python binding has been created for librgw. >>> >>> - *RBD*: >>> >>> * RBD now supports images stored in an *erasure-coded* RADOS pool >>> using the new (experimental) overwrite support. Images must be >>> created using the new rbd CLI "--data-pool " option to >>> specify the EC pool where the backing data objects are >>> stored. Attempting to create an image directly on an EC pool will >>> not be successful since the image's backing metadata is only >>> supported on a replicated pool. >>> * The rbd-mirror daemon now supports replicating dynamic image >>> feature updates and image metadata key/value pairs from the >>> primary image to the non-primary image. >>> * The number of image snapshots can be optionally restricted to a >>> configurable maximum. >>> * The rbd Python API now supports asynchronous IO operations. >>> >>> - *CephFS*: >>> >>> * libcephfs function definitions have been changed to enable proper >>> uid/gid control. The library version has been increased to reflect the >>> interface change. >>> * Standby replay MDS daemons now consume less memory on workloads >>> doing deletions. >>> * Scrub now repairs backtrace, and populates `damage ls` with >>> discovered errors. >>>
Re: [ceph-users] v11.1.0 kraken candidate released
On Tue, Dec 13, 2016 at 7:35 AM, Dietmar Rieder wrote: > Hi, > > this is good news! Thanks. > > As far as I see the RBD supports (experimentally) now EC data pools. Is > this true also for CephFS? It is not stated in the announce, so I wonder > if and when EC pools are planned to be supported by CephFS. Nobody has worked on this so far. For EC data pools, it should mainly be a case of modifying the pool validation in MDSMonitor that currently prevents assigning an EC pool. I strongly suspect we'll get around to this before Luminous. John > ~regards > Dietmar > > On 12/13/2016 03:28 AM, Abhishek L wrote: >> Hi everyone, >> >> This is the first release candidate for Kraken, the next stable >> release series. There have been major changes from jewel with many >> features being added. Please note the upgrade process from jewel, >> before upgrading. >> >> Major Changes from Jewel >> >> >> - *RADOS*: >> >> * The new *BlueStore* backend now has a stable disk format and is >> passing our failure and stress testing. Although the backend is >> still flagged as experimental, we encourage users to try it out >> for non-production clusters and non-critical data sets. >> * RADOS now has experimental support for *overwrites on >> erasure-coded* pools. Because the disk format and implementation >> are not yet finalized, there is a special pool option that must be >> enabled to test the new feature. Enabling this option on a cluster >> will permanently bar that cluster from being upgraded to future >> versions. >> * We now default to the AsyncMessenger (``ms type = async``) instead >> of the legacy SimpleMessenger. The most noticeable difference is >> that we now use a fixed sized thread pool for network connections >> (instead of two threads per socket with SimpleMessenger). >> * Some OSD failures are now detected almost immediately, whereas >> previously the heartbeat timeout (which defaults to 20 seconds) >> had to expire. This prevents IO from blocking for an extended >> period for failures where the host remains up but the ceph-osd >> process is no longer running. >> * There is a new ``ceph-mgr`` daemon. It is currently collocated with >> the monitors by default, and is not yet used for much, but the basic >> infrastructure is now in place. >> * The size of encoded OSDMaps has been reduced. >> * The OSDs now quiesce scrubbing when recovery or rebalancing is in >> progress. >> >> - *RGW*: >> >> * RGW now supports a new zone type that can be used for metadata indexing >> via Elasticseasrch. >> * RGW now supports the S3 multipart object copy-part API. >> * It is possible now to reshard an existing bucket. Note that bucket >> resharding currently requires that all IO (especially writes) to >> the specific bucket is quiesced. >> * RGW now supports data compression for objects. >> * Civetweb version has been upgraded to 1.8 >> * The Swift static website API is now supported (S3 support has been added >> previously). >> * S3 bucket lifecycle API has been added. Note that currently it only >> supports >> object expiration. >> * Support for custom search filters has been added to the LDAP auth >> implementation. >> * Support for NFS version 3 has been added to the RGW NFS gateway. >> * A Python binding has been created for librgw. >> >> - *RBD*: >> >> * RBD now supports images stored in an *erasure-coded* RADOS pool >> using the new (experimental) overwrite support. Images must be >> created using the new rbd CLI "--data-pool " option to >> specify the EC pool where the backing data objects are >> stored. Attempting to create an image directly on an EC pool will >> not be successful since the image's backing metadata is only >> supported on a replicated pool. >> * The rbd-mirror daemon now supports replicating dynamic image >> feature updates and image metadata key/value pairs from the >> primary image to the non-primary image. >> * The number of image snapshots can be optionally restricted to a >> configurable maximum. >> * The rbd Python API now supports asynchronous IO operations. >> >> - *CephFS*: >> >> * libcephfs function definitions have been changed to enable proper >> uid/gid control. The library version has been increased to reflect the >> interface change. >> * Standby replay MDS daemons now consume less memory on workloads >> doing deletions. >> * Scrub now repairs backtrace, and populates `damage ls` with >> discovered errors. >> * A new `pg_files` subcommand to `cephfs-data-scan` can identify >> files affected by a damaged or lost RADOS PG. >> * The false-positive "failing to respond to cache pressure" warnings have >> been fixed. >> >> >> Upgrading from Jewel >> >> >> * All clusters must first be upgraded to Jewel 10.2.z before upgrading >> to Kraken
Re: [ceph-users] v11.1.0 kraken candidate released
Hi, this is good news! Thanks. As far as I see the RBD supports (experimentally) now EC data pools. Is this true also for CephFS? It is not stated in the announce, so I wonder if and when EC pools are planned to be supported by CephFS. ~regards Dietmar On 12/13/2016 03:28 AM, Abhishek L wrote: > Hi everyone, > > This is the first release candidate for Kraken, the next stable > release series. There have been major changes from jewel with many > features being added. Please note the upgrade process from jewel, > before upgrading. > > Major Changes from Jewel > > > - *RADOS*: > > * The new *BlueStore* backend now has a stable disk format and is > passing our failure and stress testing. Although the backend is > still flagged as experimental, we encourage users to try it out > for non-production clusters and non-critical data sets. > * RADOS now has experimental support for *overwrites on > erasure-coded* pools. Because the disk format and implementation > are not yet finalized, there is a special pool option that must be > enabled to test the new feature. Enabling this option on a cluster > will permanently bar that cluster from being upgraded to future > versions. > * We now default to the AsyncMessenger (``ms type = async``) instead > of the legacy SimpleMessenger. The most noticeable difference is > that we now use a fixed sized thread pool for network connections > (instead of two threads per socket with SimpleMessenger). > * Some OSD failures are now detected almost immediately, whereas > previously the heartbeat timeout (which defaults to 20 seconds) > had to expire. This prevents IO from blocking for an extended > period for failures where the host remains up but the ceph-osd > process is no longer running. > * There is a new ``ceph-mgr`` daemon. It is currently collocated with > the monitors by default, and is not yet used for much, but the basic > infrastructure is now in place. > * The size of encoded OSDMaps has been reduced. > * The OSDs now quiesce scrubbing when recovery or rebalancing is in > progress. > > - *RGW*: > > * RGW now supports a new zone type that can be used for metadata indexing > via Elasticseasrch. > * RGW now supports the S3 multipart object copy-part API. > * It is possible now to reshard an existing bucket. Note that bucket > resharding currently requires that all IO (especially writes) to > the specific bucket is quiesced. > * RGW now supports data compression for objects. > * Civetweb version has been upgraded to 1.8 > * The Swift static website API is now supported (S3 support has been added > previously). > * S3 bucket lifecycle API has been added. Note that currently it only > supports > object expiration. > * Support for custom search filters has been added to the LDAP auth > implementation. > * Support for NFS version 3 has been added to the RGW NFS gateway. > * A Python binding has been created for librgw. > > - *RBD*: > > * RBD now supports images stored in an *erasure-coded* RADOS pool > using the new (experimental) overwrite support. Images must be > created using the new rbd CLI "--data-pool " option to > specify the EC pool where the backing data objects are > stored. Attempting to create an image directly on an EC pool will > not be successful since the image's backing metadata is only > supported on a replicated pool. > * The rbd-mirror daemon now supports replicating dynamic image > feature updates and image metadata key/value pairs from the > primary image to the non-primary image. > * The number of image snapshots can be optionally restricted to a > configurable maximum. > * The rbd Python API now supports asynchronous IO operations. > > - *CephFS*: > > * libcephfs function definitions have been changed to enable proper > uid/gid control. The library version has been increased to reflect the > interface change. > * Standby replay MDS daemons now consume less memory on workloads > doing deletions. > * Scrub now repairs backtrace, and populates `damage ls` with > discovered errors. > * A new `pg_files` subcommand to `cephfs-data-scan` can identify > files affected by a damaged or lost RADOS PG. > * The false-positive "failing to respond to cache pressure" warnings have > been fixed. > > > Upgrading from Jewel > > > * All clusters must first be upgraded to Jewel 10.2.z before upgrading > to Kraken 11.2.z (or, eventually, Luminous 12.2.z). > > * The ``sortbitwise`` flag must be set on the Jewel cluster before upgrading > to Kraken. The latest Jewel (10.2.4+) releases issue a health warning if > the flag is not set, so this is probably already set. If it is not, Kraken > OSDs will refuse to start and will print and error message in their log. > > > Upgrading > - > > * Th
Re: [ceph-users] v11.1.0 kraken candidate released
It looks like the second releasenote in that section answers my question. sortbitwise is only supported in jewel, and it's required to be already set for Kraken upgraded OSDs to even start up, so one must go to Jewel first. The section heading should probably say just "Upgrading to Kraken" rather than "Upgrading from Jewel". Also, there is a whole 'upgrading, release by release' section in the documentation which hasn't been updated since Firefly. Someone, perhaps me, should probably update those... It's a little easier to follow that path of upgrade notes. (though reading release notes is also required) http://docs.ceph.com/docs/master/install/upgrading-ceph/ -Ben On Mon, Dec 12, 2016 at 6:35 PM, Ben Hines wrote: > Hi! Can you clarify whether this release note applies to Jewel upgrades > only? Ie, can we go Infernalis -> Kraken? It is in the 'upgrading from > jewel' section which would imply that it doesn't apply to Infernalis -> > Kraken. (or any other version to kraken), but it does say 'All clusters'. > > Upgrading from Jewel > > * All clusters must first be upgraded to Jewel 10.2.z before upgrading > to Kraken 11.2.z (or, eventually, Luminous 12.2.z). > > thanks! > > -Ben > > > On Mon, Dec 12, 2016 at 6:28 PM, Abhishek L > wrote: > >> Hi everyone, >> >> This is the first release candidate for Kraken, the next stable >> release series. There have been major changes from jewel with many >> features being added. Please note the upgrade process from jewel, >> before upgrading. >> >> Major Changes from Jewel >> >> >> - *RADOS*: >> >> * The new *BlueStore* backend now has a stable disk format and is >> passing our failure and stress testing. Although the backend is >> still flagged as experimental, we encourage users to try it out >> for non-production clusters and non-critical data sets. >> * RADOS now has experimental support for *overwrites on >> erasure-coded* pools. Because the disk format and implementation >> are not yet finalized, there is a special pool option that must be >> enabled to test the new feature. Enabling this option on a cluster >> will permanently bar that cluster from being upgraded to future >> versions. >> * We now default to the AsyncMessenger (``ms type = async``) instead >> of the legacy SimpleMessenger. The most noticeable difference is >> that we now use a fixed sized thread pool for network connections >> (instead of two threads per socket with SimpleMessenger). >> * Some OSD failures are now detected almost immediately, whereas >> previously the heartbeat timeout (which defaults to 20 seconds) >> had to expire. This prevents IO from blocking for an extended >> period for failures where the host remains up but the ceph-osd >> process is no longer running. >> * There is a new ``ceph-mgr`` daemon. It is currently collocated with >> the monitors by default, and is not yet used for much, but the basic >> infrastructure is now in place. >> * The size of encoded OSDMaps has been reduced. >> * The OSDs now quiesce scrubbing when recovery or rebalancing is in >> progress. >> >> - *RGW*: >> >> * RGW now supports a new zone type that can be used for metadata >> indexing >> via Elasticseasrch. >> * RGW now supports the S3 multipart object copy-part API. >> * It is possible now to reshard an existing bucket. Note that bucket >> resharding currently requires that all IO (especially writes) to >> the specific bucket is quiesced. >> * RGW now supports data compression for objects. >> * Civetweb version has been upgraded to 1.8 >> * The Swift static website API is now supported (S3 support has been >> added >> previously). >> * S3 bucket lifecycle API has been added. Note that currently it only >> supports >> object expiration. >> * Support for custom search filters has been added to the LDAP auth >> implementation. >> * Support for NFS version 3 has been added to the RGW NFS gateway. >> * A Python binding has been created for librgw. >> >> - *RBD*: >> >> * RBD now supports images stored in an *erasure-coded* RADOS pool >> using the new (experimental) overwrite support. Images must be >> created using the new rbd CLI "--data-pool " option to >> specify the EC pool where the backing data objects are >> stored. Attempting to create an image directly on an EC pool will >> not be successful since the image's backing metadata is only >> supported on a replicated pool. >> * The rbd-mirror daemon now supports replicating dynamic image >> feature updates and image metadata key/value pairs from the >> primary image to the non-primary image. >> * The number of image snapshots can be optionally restricted to a >> configurable maximum. >> * The rbd Python API now supports asynchronous IO operations. >> >> - *CephFS*: >> >> * libcephfs function definitions have been changed t
Re: [ceph-users] v11.1.0 kraken candidate released
Hi! Can you clarify whether this release note applies to Jewel upgrades only? Ie, can we go Infernalis -> Kraken? It is in the 'upgrading from jewel' section which would imply that it doesn't apply to Infernalis -> Kraken. (or any other version to kraken), but it does say 'All clusters'. Upgrading from Jewel * All clusters must first be upgraded to Jewel 10.2.z before upgrading to Kraken 11.2.z (or, eventually, Luminous 12.2.z). thanks! -Ben On Mon, Dec 12, 2016 at 6:28 PM, Abhishek L wrote: > Hi everyone, > > This is the first release candidate for Kraken, the next stable > release series. There have been major changes from jewel with many > features being added. Please note the upgrade process from jewel, > before upgrading. > > Major Changes from Jewel > > > - *RADOS*: > > * The new *BlueStore* backend now has a stable disk format and is > passing our failure and stress testing. Although the backend is > still flagged as experimental, we encourage users to try it out > for non-production clusters and non-critical data sets. > * RADOS now has experimental support for *overwrites on > erasure-coded* pools. Because the disk format and implementation > are not yet finalized, there is a special pool option that must be > enabled to test the new feature. Enabling this option on a cluster > will permanently bar that cluster from being upgraded to future > versions. > * We now default to the AsyncMessenger (``ms type = async``) instead > of the legacy SimpleMessenger. The most noticeable difference is > that we now use a fixed sized thread pool for network connections > (instead of two threads per socket with SimpleMessenger). > * Some OSD failures are now detected almost immediately, whereas > previously the heartbeat timeout (which defaults to 20 seconds) > had to expire. This prevents IO from blocking for an extended > period for failures where the host remains up but the ceph-osd > process is no longer running. > * There is a new ``ceph-mgr`` daemon. It is currently collocated with > the monitors by default, and is not yet used for much, but the basic > infrastructure is now in place. > * The size of encoded OSDMaps has been reduced. > * The OSDs now quiesce scrubbing when recovery or rebalancing is in > progress. > > - *RGW*: > > * RGW now supports a new zone type that can be used for metadata indexing > via Elasticseasrch. > * RGW now supports the S3 multipart object copy-part API. > * It is possible now to reshard an existing bucket. Note that bucket > resharding currently requires that all IO (especially writes) to > the specific bucket is quiesced. > * RGW now supports data compression for objects. > * Civetweb version has been upgraded to 1.8 > * The Swift static website API is now supported (S3 support has been > added > previously). > * S3 bucket lifecycle API has been added. Note that currently it only > supports > object expiration. > * Support for custom search filters has been added to the LDAP auth > implementation. > * Support for NFS version 3 has been added to the RGW NFS gateway. > * A Python binding has been created for librgw. > > - *RBD*: > > * RBD now supports images stored in an *erasure-coded* RADOS pool > using the new (experimental) overwrite support. Images must be > created using the new rbd CLI "--data-pool " option to > specify the EC pool where the backing data objects are > stored. Attempting to create an image directly on an EC pool will > not be successful since the image's backing metadata is only > supported on a replicated pool. > * The rbd-mirror daemon now supports replicating dynamic image > feature updates and image metadata key/value pairs from the > primary image to the non-primary image. > * The number of image snapshots can be optionally restricted to a > configurable maximum. > * The rbd Python API now supports asynchronous IO operations. > > - *CephFS*: > > * libcephfs function definitions have been changed to enable proper > uid/gid control. The library version has been increased to reflect the > interface change. > * Standby replay MDS daemons now consume less memory on workloads > doing deletions. > * Scrub now repairs backtrace, and populates `damage ls` with > discovered errors. > * A new `pg_files` subcommand to `cephfs-data-scan` can identify > files affected by a damaged or lost RADOS PG. > * The false-positive "failing to respond to cache pressure" warnings have > been fixed. > > > Upgrading from Jewel > > > * All clusters must first be upgraded to Jewel 10.2.z before upgrading > to Kraken 11.2.z (or, eventually, Luminous 12.2.z). > > * The ``sortbitwise`` flag must be set on the Jewel cluster before > upgrading > to Kraken. The latest Jewel (10.2.4+) releases issue a
[ceph-users] v11.1.0 kraken candidate released
Hi everyone, This is the first release candidate for Kraken, the next stable release series. There have been major changes from jewel with many features being added. Please note the upgrade process from jewel, before upgrading. Major Changes from Jewel - *RADOS*: * The new *BlueStore* backend now has a stable disk format and is passing our failure and stress testing. Although the backend is still flagged as experimental, we encourage users to try it out for non-production clusters and non-critical data sets. * RADOS now has experimental support for *overwrites on erasure-coded* pools. Because the disk format and implementation are not yet finalized, there is a special pool option that must be enabled to test the new feature. Enabling this option on a cluster will permanently bar that cluster from being upgraded to future versions. * We now default to the AsyncMessenger (``ms type = async``) instead of the legacy SimpleMessenger. The most noticeable difference is that we now use a fixed sized thread pool for network connections (instead of two threads per socket with SimpleMessenger). * Some OSD failures are now detected almost immediately, whereas previously the heartbeat timeout (which defaults to 20 seconds) had to expire. This prevents IO from blocking for an extended period for failures where the host remains up but the ceph-osd process is no longer running. * There is a new ``ceph-mgr`` daemon. It is currently collocated with the monitors by default, and is not yet used for much, but the basic infrastructure is now in place. * The size of encoded OSDMaps has been reduced. * The OSDs now quiesce scrubbing when recovery or rebalancing is in progress. - *RGW*: * RGW now supports a new zone type that can be used for metadata indexing via Elasticseasrch. * RGW now supports the S3 multipart object copy-part API. * It is possible now to reshard an existing bucket. Note that bucket resharding currently requires that all IO (especially writes) to the specific bucket is quiesced. * RGW now supports data compression for objects. * Civetweb version has been upgraded to 1.8 * The Swift static website API is now supported (S3 support has been added previously). * S3 bucket lifecycle API has been added. Note that currently it only supports object expiration. * Support for custom search filters has been added to the LDAP auth implementation. * Support for NFS version 3 has been added to the RGW NFS gateway. * A Python binding has been created for librgw. - *RBD*: * RBD now supports images stored in an *erasure-coded* RADOS pool using the new (experimental) overwrite support. Images must be created using the new rbd CLI "--data-pool " option to specify the EC pool where the backing data objects are stored. Attempting to create an image directly on an EC pool will not be successful since the image's backing metadata is only supported on a replicated pool. * The rbd-mirror daemon now supports replicating dynamic image feature updates and image metadata key/value pairs from the primary image to the non-primary image. * The number of image snapshots can be optionally restricted to a configurable maximum. * The rbd Python API now supports asynchronous IO operations. - *CephFS*: * libcephfs function definitions have been changed to enable proper uid/gid control. The library version has been increased to reflect the interface change. * Standby replay MDS daemons now consume less memory on workloads doing deletions. * Scrub now repairs backtrace, and populates `damage ls` with discovered errors. * A new `pg_files` subcommand to `cephfs-data-scan` can identify files affected by a damaged or lost RADOS PG. * The false-positive "failing to respond to cache pressure" warnings have been fixed. Upgrading from Jewel * All clusters must first be upgraded to Jewel 10.2.z before upgrading to Kraken 11.2.z (or, eventually, Luminous 12.2.z). * The ``sortbitwise`` flag must be set on the Jewel cluster before upgrading to Kraken. The latest Jewel (10.2.4+) releases issue a health warning if the flag is not set, so this is probably already set. If it is not, Kraken OSDs will refuse to start and will print and error message in their log. Upgrading - * The list of monitor hosts/addresses for building the monmap can now be obtained from DNS SRV records. The service name used in when querying the DNS is defined in the "mon_dns_srv_name" config option, which defaults to "ceph-mon". * The 'osd class load list' config option is a list of object class names that the OSD is permitted to load (or '*' for all classes). By default it contains all existing in-tree classes for backwards compatibility. * The 'osd class default list' config option is a list of
