[Deepsea-users] Fwd: v11.1.0 kraken candidate released
lmb at suse.com
Wed Dec 14 03:19:13 MST 2016
On 2016-12-13T09:28:31, Eric Jackson <ejackson at suse.com> wrote:
> * 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.
> I think we should create an alternate default now (e.g. default-bluestore.sls)
> for the OSDs. However, by the time this is tested/verified, maybe BlueStore
> should be the default prior to Luminous.
Yes, we should make the OSD deployment more easily customizable; I'd
personally think that this configuration should be in the pillars
somewhere and expose the various options.
> * 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
> is defined in the "mon_dns_srv_name" config option, which defaults to
> Sites that wish to remove the hardcoded monitor names/addresses from ceph.conf
> will like this. I think the ceph/configuration needs an alternate default
> (default-dns-srv.sls or something).
Yes. And then we may want to consider how to push the IPs into the DNS
server, but that may be out of our scope if we make it really easy to
"list all MON public IPs" so they can push this.
> * If you have manually specified the monitor user rocksdb via the
> ``mon keyvaluedb = rocksdb`` option, you will need to manually add a
> file to the mon data directory to preserve this option::
> echo rocksdb > /var/lib/ceph/mon/ceph-`hostname`/kv_backend
> New monitors will now use rocksdb by default, but if that file is
> not present, existing monitors will use leveldb. The ``mon
> keyvaluedb`` option now only affects the backend chosen when a
> monitor is created.
> What do others think of rocksdb? Would you want this as an alternate default?
> Should this be the default?
I think it should be the default so we can test it better. BlueStore
also uses this in the back. Should be another configuration option.
> * The jerasure and shec plugins can now detect SIMD instruction at
> runtime and no longer need to be explicitly configured for different
> processors. The following plugins are now deprecated:
> jerasure_generic, jerasure_sse3, jerasure_sse4, jerasure_neon,
> shec_generic, shec_sse3, shec_sse4, and shec_neon. If you use any of
> these plugins directly you will see a warning in the mon log file.
> Please switch to using just 'jerasure' or 'shec'.
> I've never known what the "right" answer is to erasure coded pools. Do you
> leave it to interested parties to go "read the documentation" or is this
> something that is worthy of a working example for both jerasure and shec?
I think this is something that users need to configure, and deciding how
the pools should be configured is more of a topic for openATTIC's UI in
our stack, I believe.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
More information about the Deepsea-users