Make the proxy single user about accumulo-proxy

[milleruntime]

I'm not sure what's going on with the ITs. It may be entirely unrelated.

See #31

[ctubbsii]

Under this paradigm, it still would be possible to support multiple users with a single proxy. However, the way it would be done is much simpler: you simply specify which client properties file the proxy should use to create AccumuloClient objects for the requested operations.

[mikewalch]

Under this paradigm, it still would be possible to support multiple users with a single proxy. However, the way it would be done is much simpler: you simply specify which client properties file the proxy should use to create AccumuloClient objects for the requested operations.

Does the proxy client need to be on the same server as the Proxy if this is done? There are Java bindings in case you want to limit access from the client to cluster. I am not sure if limiting access is still needed, I just wanted to bring it up.

[ctubbsii]

Does the proxy client need to be on the same server as the Proxy if this is done?

No. The client just needs to send a filename for a file that exists local to the proxy server... or, it could send the raw client properties, I suppose. The main point is to standardize client initialization around the client properties, either as raw properties or as a properties file, rather than the custom "logon" session stuff that the proxy has now. Avoiding the custom stuff and using the client properties in the same (familiar) way that the Java API uses them, would be the main goal.

The simplest thing to do is just have one set of client properties in the proxy server so it has one Java AccumuloClient for the lifetime of the proxy, to handle all the real client's requests. That implies a single-user scenario, so that's why I thought of that first.

The more complicated case would be the multi-user support via multiple sets of client properties. I haven't fully through through all the possible multi-user options and their implications... but just thinking that it could still be done, if we really wanted to have that complexity.

Which direction this goes is really up to user demand and how tolerant for complexity those maintaining the proxy are. I'm fine with the single user case (because my tolerance for complexity in Accumulo is low right now)... I just want to see the custom and unfamiliar proxy-specific stuff go away in favor of the friendly and familiar client properties.

[milleruntime]

@ctubbsii With the update in Accumulo 2.0.1, most of the ITs are throwing security exceptions. I have been looking where the user "user" gets setup but have not found that yet. I am wondering if this ticket is more important now that the exception bug was fixed in: apache/accumulo#1828

Edit: The ITs can still pass but they are throwing security exceptions.

[ctubbsii]

@ctubbsii With the update in Accumulo 2.0.1, most of the ITs are now failing. I have been looking where the user "user" gets setup but have not found that yet. I am wondering if this ticket is more important now that the exception bug was fixed in: apache/accumulo#1828

I'm not sure how this ticket would relate to that one. The idea here is to just create a single AccumuloClient for that specific proxy instance, built from the client properties, and remove any "login" mechanisms.

I'm not sure what's going on with the ITs. It may be entirely unrelated.

[DomGarguilo]

Is the suggestion here to pass the client properties when creating the Accumuloproxy.Client which will be used to create the AccumuloClient once, which will then be used for all operations without having to pass in the "login" every time we want to do an operation?

[ctubbsii]

Is the suggestion here to pass the client properties when creating the Accumuloproxy.Client which will be used to create the AccumuloClient once, which will then be used for all operations without having to pass in the "login" every time we want to do an operation?

The suggestion is that starting the AccumuloProxy (via it's main method) will either automatically locate the client properties using the class path and/or environment and construct an AccumuloClient from that (just like bin/accumulo jshell does). I'm not sure what features we have right now to explicitly set the path to the client properties file... it might be a Java system property you can set with -Daccumulo.properties=/path/to/file or similar... but that should work also. The user should have to do nothing to construct the AccumuloClient object inside the proxy service. We may want to add some mechanism for the proxy client to authenticate to the proxy service, but that can be addressed later. The first pass, is just to simplify the proxy service authenticating to Accumulo.

[DomGarguilo]

Addressed in #59