Relocate accumulo-proxy to separate repository on its own release schedule about accumulo-proxy

[hkeebler]

Working this ticket instead of 1180

[cjmctague]

This can be closed.
https://github.com/apache/accumulo-proxy

[milleruntime]

@cjmctague thanks!

[milleruntime]

Nope sorry, this is partially done. Still some proxy tests that need to be migrated.

[ctubbsii]

Yeah, sorry, the new repo was created, but the old proxy code is still there. It needs to be removed, and cross-referenced with the new repo, to make sure everything made it over before it is removed. I think some tests were still dependent on the proxy, maybe some minicluster features were using it also. Not sure.

[milleruntime]

@cjmctague Are you interested in working on this?

[cjmctague]

@milleruntime Yea sure. So tests need to be moved over and the current tests using the proxy need to be ported to use the new repo?

[ctubbsii]

@milleruntime Yea sure. So tests need to be moved over and the current tests using the proxy need to be ported to use the new repo?

Tests which test the proxy should be moved over. Tests which aren't testing the proxy shouldn't be using the proxy. The proxy repo should depend on the main Accumulo repo, but not the other way around.

[hkeebler]

Status: Updated accumulo-proxy project from the accumulo proxy module including version updates and was able to get it to build and test runs. Now I'll look into using the jar with the accumulo project instead of proxy module.

[hkeebler]

@ctubbsii the accumulo-proxy contrib subdirectory has a create-release-candidate.sh script which does not exist in the accumulo project. I'm not sure what it does and why it is there. Just curious.

[hkeebler]

Running a verify gave me this [ERROR] Exception is caught when Exception is not thrown in org.apache.accumulo.proxy.ProxyServer.updateRowsConditionally(String, Map) [org.apache.accumulo.proxy.ProxyServer] At ProxyServer.java:[line 2207] REC_CATCH_EXCEPTION

the code line is

} catch (Exception e) {
      handleException(e);
      return null;
    }

This apparently verifies okay in the accumulo project so why is it failing here - I'm not savvy with verify. I changed the catch to the following and it verifies but not sure if you have better suggestions.

} catch (Throwable e) {
      handleException(new Exception(e));
      return null;
    }

[ctubbsii]

@hkeebler I transferred this issue from apache/accumulo#454 to this accumulo-proxy project, because all the work needed to be done is in this repository.

[ctubbsii]

@ctubbsii the accumulo-proxy contrib subdirectory has a create-release-candidate.sh script which does not exist in the accumulo project. I'm not sure what it does and why it is there. Just curious.

Accumulo has a script to prepare release candidates for voting. Moving this to its own repository means it would be released separately. So, that file was added to make it more convenient to release new versions of the proxy.

[hkeebler]

@ctubbsii I assume you want the integrated tests in this project. I'm having trouble getting them to run. They seem to hang logging into the client - ByteBuffer login = client.login("root", properties);
When trying the debug process I lose the drill down. Any ideas off the top of your head?

[hkeebler]

Re-phrasing the last question. It is hanging because the Tserver cannot use the accumulo native libs. If I set cfg.setProperty(Property.TSERV_NATIVEMAP_ENABLED, "false"); then it runs. BUT I probably should figure out how to get the native lib to build in the test scenario. Looking into that now.

[hkeebler]

Actually I am going with leaving the native libs as false unless someone thinks otherwise. Additionally, It ooks like the "thrift" generated code is checked into the git repository. Should it be?

[ctubbsii]

Without the native libs is fine. These ITs don't need to assume the native libs exist.

[ctubbsii]

Generally, we check in the thrift code during development, because they don't change very often, and not all developers have thrift installed (because it's a pain to build from source, and most distros don't have the right version in an RPM/DEB). We tend to regenerate them whenever we make a thrift change, or when we do releases.

I'm not sure if we check in the generated code for the proxy during normal development, or if we only build those for the tarball when we release.