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
> > 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
> > > But all the really secret stuff should be in the site.xml which
> > > get exposed.
> > >
> > > For reference, ZooKeeperInstance's getConfiguration() is implemented
> > > 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