Re: experimental features

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

 



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
_______________________________________________
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