Re: experimental features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 12/05/2014 11:39 AM, Gregory Farnum wrote:
On Fri, Dec 5, 2014 at 9:36 AM, Sage Weil <sweil@xxxxxxxxxx> wrote:
A while back we merged Haomai's experimental OSD backend KeyValueStore.
We named the config option 'keyvaluestore_dev', hoping to make it clear to
users that it was still under development, not fully tested, and not yet
ready for production.  In retrospect, I don't think '_dev' was
sufficiently scary because many users tried it and ran into
unexpectd trouble.

There are several other features we've recently added or are considering
adding that fall into this category.  Having them in the tree is great
because it streamlines QA and testing, but I want to make sure that
users are not able to enable the features without being aware of the
risks.

A few possible suggestions:

- scarier option names, like

   osd objectstore = keyvaluestore_experimental_danger_danger
   ms type = async_experimental_danger_danger
   ms type = xio_experimental_danger_danger

   Once the feature becomes stable, they'll have to adjust their
config, or we'll need to support both names going forward.

- a separate config option that allows any experimental option

   allow experimental features danger danger = true
   osd objectstore = keyvaluestore
   ms type = xio

   This runs the risk that the user will enable experimental features to
get X, and later start using Y without realizing Y is also
experiemental.

- enumerate experiemntal options we want to enable

   allow experimental features danger danger = keyvaluestore, xio
   ms type = xio
   osd objectstore = keyvaluestore

   This has the property that no config change is necessary when the
feature drops its experimental status.

In all of these cases, we can also make a point of sending something to
the log on daemon startup.  I don't think too many people will notice
this, but it is better than nothing.

Other ideas?

I don't think these should even be going into release packages for
users to work with. We can build them on the dev gitbuilders for QA
and testing without them ever reaching the hands of users grabbing our
production packages. ;)
-Greg
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


I'm in favor of the "allow experimental features" but instead call it:

"ALLOW UNRECOVERABLE DATA CORRUPTING FEATURES" which makes things a little more explicit. With great power comes great responsibility.

Mark
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux