The reason I'm interested in the config from a ZooKeeperInstance is because a ZKInstance needs to know whether or not to use SSL to try to connect to a given cluster. I think it would be annoying to require a ZKInstance client to explicitly specify "useSsl" any time they want to connect to an SSL tserver (although I do see value in having a "requireSsl" optional flag). If configuration isn't the right way to communicate this, do people have other suggestions? I suppose I could just throw an ssl:// on the front of the connection string or something, but it seems kludgy to do that any time there's a configuration option that we want clients to know about.
As far as removing Instance.getConfiguration() entirely, there are about 30 references throughout the codebase to getConfiguration() on a bare Instance. Finding some other way to plumb whatever options those consumers care about through the stack sounds like a substantial project. In my use case, I am only interested in the configuration that's stored in ZK, and I already have enough information to connect to ZK, so it doesn't seem difficult technically, just a question of desired behavior. On Tue, Jul 23, 2013 at 1:11 PM, Eric Newton <[email protected]> wrote: > +1 for removing it from Instance > > > On Tue, Jul 23, 2013 at 12:14 PM, Christopher <[email protected]> wrote: > > > It only returns the default config if you don't call > > setConfiguration(), which appears to be almost always (except > > TestIngest). > > > > I don't know that this API is clearly spelled out, as to its intended > > purpose. Which configuration is it supposed to be getting, and how > > does that relate to the ZooKeeperInstance? The only configuration a > > ZooKeeperInstance has is the minimum needed to connect to other > > servers. It still has to authenticate to read any other server > > configuration. > > > > Personally, I'd be in favor of removing it from Instance interface, > > unless we actually document what it is supposed to be for to justify > > its utility in, and relationship to, the Instance interface. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, Jul 23, 2013 at 10:44 AM, Michael Berman <[email protected]> > > wrote: > > > I was surprised to find that ZooKeeperInstance.getConfiguration() seems > > to > > > return only the default configuration rather than the configuration > > stored > > > in ZK. Is this the expected behavior? I came across this in a > MacTest, > > so > > > if other people are also surprised, it may be a MAC or MacTest-specific > > > issue, in which case I'm happy to track it down. > > > > > > If this is currently the expected behavior, how would people feel about > > > changing it? It seems like it would be useful to have a config channel > > to > > > ZooKeeperInstance clients (in my case, what I'm specifically interested > > in > > > is whether or not SSL is enabled). There may be a potential for > > privileged > > > information to escape...table settings, for example, may be > sensitive... > > > But all the really secret stuff should be in the site.xml which > wouldn't > > > get exposed. > > > > > > For reference, ZooKeeperInstance's getConfiguration() is implemented > as: > > > AccumuloConfiguration.getDefaultConfiguration() > > > > > > whereas HdfsZooInstance's getConfiguration() is: > > > ZooConfiguration.getInstance(this, getSiteConfiguration()) > > > > > > My proposal would be to change ZooKeeperInstance's to something like: > > > ZooConfiguration.getInstance(this, > > > AccumuloConfiguration.getDefaultConfiguration()) > > > > > > Michael > > >
