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
 |