On Fri, Apr 17, 2020 at 3:31 PM Stack <st...@duboce.net> wrote: > On writing to local 'tmp' dir, thats fine, but quickstart was always > supposed to be a transient install (its one example of setting config is > the setting of the tmp location). The messaging that this is the case needs > an edit after a re-read (I volunteer to do this and to give refguide a > once-over on lack of guarantees when an hbase deploy is unconfigured). >
Sounds like you're reading my handiwork, pushed in HBASE-24106. I'm definitely open to editing help, yes please! Before that change, the Quick Start section required the user to set hbase.rootdir, hbase.zookeeper.property.dataDir, and hbase.unsafe.stream.capability.enforce all before that could start the local process. Can we have the start-out-of-the-box back please? Its a PITA having to go > edit config running a local build trying to test something nevermind the > poor noob whose first experience is a fail. > I agree. The conclusion I understand from this thread looks something like this: 1. revert HBASE-24086, make it so that running on `LocalFileSystem` is a fatal condition with default configs. 2. ship a conf/hbase-site.xml that contains hbase.unsafe.stream.capability.enforce=false, along with a big comment saying this is not safe for production. 3. ship a conf/hbase-site.xml that contains hbase.tmp.dir=./tmp, along with a comment saying herein you'll find temporary and persistent data, reconfigure for production with hbase.rootdir pointed to a durable filesystem that supports our required stream capabilities (see above). 4. update HBASE-24106 as appropriate. Neither 2 nor 3 are suitable for production deployments, thus the changes do not go into hbase-default.xml. Anyone standing up a production deploy must edit hbase-site.xml anyway, so this doesn't change anything. It also restores our "simple" first-time user experience of not needing to run anything besides `bin/start-hbase.sh` (or `bin/hbase master start`, or whatever it is we're telling people these days). We can reassess this once more when a durable equivalent to LocalFileSystem comes along. Thanks, Nick
