The ticket for documentation exists: https://issues.apache.org/jira/browse/ACCUMULO-3851
I'm going to unassign it from myself. I think it's important to document, but I had nothing to do with it's implementation, so I'll let someone more knowledgeable tackle it. On Tue, Jun 30, 2015 at 11:01 PM, Christopher <[email protected]> wrote: > That's correct. And, that's precisely the kind of things it'd be nice to > add. I would say that it's on the agenda. > > On Tue, Jun 30, 2015, 21:08 Max Thomas <[email protected]> wrote: > >> Christopher/Josh - thanks for the quick responses. >> >> I certainly understand the concerns about passing around >> accumulo-site.xml. While I haven't had any issues with this, based on >> poking around ClientConfiguration.java it seems that it was necessary >> for various SSL/Kerberos features. >> >> Forgive what might be a very naive question, but: currently, as a >> consumer of an Accumulo from Java, I've got to provide (minimally) a >> username, password, instance name, and zookeeper server string. Based on >> a brief scan of ClientConfiguration, though, it does not seem that the >> username/password will be read from client.conf - is that correct? Will >> support for that be added in the future? >> >> On 6/30/15 8:07 PM, Josh Elser wrote: >> > I'll open up a documentation ticket. I thought we had something in there >> > but maybe not. >> > >> > For a normal instance, this file would likely just contain >> > >> > instance.zookeeper.host=zkserver1,zkserver2,etc.. >> > >> > Like Christopher says, it's not required yet, but it would be a good >> > habit to start using it as it's the direction we're heading. >> > >> > Christopher wrote: >> >> In short, yes, it will likely be required for clients in the future >> >> (if you want something other than the defaults). >> >> >> >> The longer answer is that we just wanted to make sure the user >> >> understood where their configuration is coming from, in case things >> >> aren't working as they expect. >> >> >> >> We've been moving towards separating the server-side configuration >> >> (mostly, accumulo-site.xml) from client utilities, due to the fact >> >> that a client cannot be expected to have access to the >> >> accumulo-site.xml (it contains a sensitive instance.secret and other >> >> stuff a client doesn't need), and it can be confusing to have a >> >> client-specific "accumulo-site.xml", which is not the server's >> >> "accumulo-site.xml". >> >> >> >> If you don't have this file, it will fall back to reasonable defaults >> >> (reading "accumulo-site.xml" from the classpath, if one is available). >> >> >> >> Some of this behavior is a bit screwy, but we've been careful to >> >> preserve backwards compatibility as much as possible. In the future, >> >> it is my intention (and perhaps others share this goal with me) to >> >> clean up these configs quite a bit. So, if you have any suggestions on >> >> how you think things should work, feedback is always welcome. >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> >> >> >> On Tue, Jun 30, 2015 at 7:37 PM, Max Thomas<[email protected]> >> wrote: >> >>> When running code against a 1.7.0 cluster, the following warning keeps >> >>> appearing: >> >>> >> >>> 2015-06-30 19:32:58,352 WARN o.a.a.c.c.ClientConfiguration [main] >> >>> Found no >> >>> client.conf in default paths. Using default client configuration >> values. >> >>> >> >>> The only mention of this file that I can find, however, is in the >> manual >> >>> buried in a section on Kerberos. >> >>> >> >>> Is this a warning because this will be required for clients in the >> >>> future? >> >
