-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-26838 Junit jar is not included in the hbase tar ball, causing … #4223
Conversation
…issues for some hbase tools that do rely on it
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@@ -159,6 +160,8 @@ | |||
<include>io.opentelemetry.javaagent:*</include> | |||
</includes> | |||
</dependencySet> | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why these two blank lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me remove it.
|
||
<!-- Adds junit libs to lib/test --> | ||
<dependencySet> | ||
<outputDirectory>lib/test</outputDirectory> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we load the libraries under this package?
And better also include hamcrest here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, these libraries would be packed under a "lib\test" folder, and would not be added to hbase classpath automatically (the hbase script, by default, puts "lib*" on the CP).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean we should add these libraries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean add to hbase classpath by default? Junit used to be shipped until it was scoped for test only on all modules, at least since release 2.4 (In 2.2 it was still shipped). In general, HBase processes seem to work pretty fine without it on the CP. The only setback is for the test tooling, such as IntegrationTestIngest
, which will now fail without junit lib in the classpath.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how do we setback when executing IntegrationTestIngest? Manually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this could be easily done as HBASE_CLASSPATH="$HBASE_HOME/lib/tests/*" hbase org.apache.hadoop.hbase.IntegrationTestIngest -m slowDeterministic
, since we already provide the lib within the tarball. We could update the ref guide section accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what is the problem if we always add these jars to our classpath? At lease when running tools(not daemon services)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ehh, usually it's been a thing that causes people to ask questions rather than something actually breaking. Apparently others think that we shouldnt' have this on the $CLASSPATH given they removed them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, it is a security and release hygiene issue to ship test dependencies in the runtime. It is problematic for me that some of our user utilities have runtime dependency on test jars. Only mildly related: I'm curious how much extra space those test dependencies consume in our release artifacts.
Short of the restructuring that I suggested, I am okay with this approach of isolating these test dependencies in their own directory and conditionally including them at runtime. If there are classes that we know require them, our bin/hbase
script can intelligently add them to the classpath for those classes. Doing so will preserve backward compatibility while also keeping the extra jars out of the daemon services' classpaths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let me add it to the CP of the tools that require it, in bin/hbase
script.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
I find all this very problematic. Our IntegrationTest classes are in a If we want to ship the IntegrationTest classes in our binary distribution, what we need to do is restructure hbase-it so that the IntegrationTest jars are in |
Well, we already ship those and document its use on the ref guide. The problem is that we also make it possible to be run as junit tests, through maven builds, so I think that's why those are originally placed under |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming these show up only in the right place, this changeset looks correct (meaning, I didn't build and validate what you did -- I trust you here :))
|
||
<!-- Adds junit libs to lib/test --> | ||
<dependencySet> | ||
<outputDirectory>lib/test</outputDirectory> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ehh, usually it's been a thing that causes people to ask questions rather than something actually breaking. Apparently others think that we shouldnt' have this on the $CLASSPATH given they removed them.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
…to include junit lib in the CP
@@ -757,6 +757,13 @@ elif [ "$COMMAND" = "hbtop" ] ; then | |||
HBASE_OPTS="${HBASE_OPTS} ${HBASE_HBTOP_OPTS}" | |||
else | |||
CLASS=$COMMAND | |||
if [[ "$CLASS" =~ .*IntegrationTest.* ]] ; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndimiduk , I believe all classes on hbase-it which are exposed for running standalone follow this naming pattern. These are spread over few different packages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's quite a few more classes than that.
$ grep 'public static void main' -cirIF hbase-it/src --include *.java | grep -v IntegrationTest | grep -v Action | wc -l
46
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I had noticed before that there were few others with a main method, but the only ones really relying on junit are the "IntegrationTest" ones.
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mean to thrash things around. But I read through the changes here and the discussion around how to tell which classes in the test jars are magically detected for including this classpath and it all feels prohibitively brittle.
If I'm a developer adding in something I want run as a test on a live cluster how do I know what I have to do to get it to work here?
If I'm an operator how am I supposed to reason about which utilities get included for running with these "hbase test dependencies"?
I looked at the ref guide and I see two candidate starting points for how I'd figure this out.
- The troubleshooting section "Running unit or integration tests"
- The operations section "Tools and utilities"
But neither of them actually have any relevant details.
I know this has accidentally worked in the past by "just" running the class. Could we instead be intentional about things?
What if we add a new command to the hbase script similar to the one for ltt
that is for running integration tests specifically? Something like it-test
? That could add in the needed classpath. I am indifferent to wether folks specify which test via a fully qualified classname or a short class name. We could have it list the available classes when none is given. Then a small update to the ref guide that points folks to that listing and I guess javadocs for the listed classes would give a much needed foothold to someone who want to use this stuff.
I don't know what the other classes with main methods are in hbase-it
are, but if they are supposed to be run against a cluster we ought to be able to similarly categorize them. Not everything with a main method is meant for running on a cluster, but there should be some kind of note about that in the javadocs for the class or method.
Yeah, not much defences here other than documenting it.
If we ever figure out in the
Not only that, but now the sections about running IT and chaos monkey in the ref guide are broken, because they explicitly mention some classes to be run from
We could do it, but would break compatibility. For example, imagine some automated QA process that invokes a set of these IT classes. Until 2.4, it was working by just running
Yeah, looks like docs update is a must. Could we go with it by adding developer guidelines notices on the ref guide, javadocs and hbase-it readme that in case of any junit (or other test only lib) dependent exposed tool addition to hbase-it would require review of classpath definition in |
I just want to come with some humility to ask that we don't look past fixing this immediate problem (to restore how things previously could work) to build an ideal solution. I would very much love to have our integration test code exposed via src/main/java so that maven transitive dependencies work, and JUnit wrappers so that they can be automatically invoked by a maven lifecycle phase. I also know that just because something previously could work in a certain way, doesn't mean that it was intentional to work that way (as Busbey pointed out -- this isn't 100% clear in the Book). I think we're all on the same page that this is a gap and it would be great to make meaningful changes to close those gaps. I just want to reinforce that we have a number of test suites at $dayjob which have now been broken for some time without any remediation. Wellington's current changes will help solve that problem and we can take our time to figure out how we want standalone tests to work in HBase with less urgency attached to it. |
Ping @busbey @ndimiduk , considering mine and Josh's latest comments observations, would you still see this approach as -1, or can we go ahead with this solution for now, provided that I add reg-guide/readme comments/javadocs explaining the pre-condition for test libs to be automatically loaded into the CP by hbase script? |
Yep, in the sprit of "get it mostly fixed," I think what you have is pretty good. I did a quick search -- I think you need to include mockito in the test jars as well -- if it's not already.
|
That's a good catch :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at your current PR branch, hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/actions/TestChangeSplitPolicyAction.java
is the only use of Mockito and I don't think this one has standalone "merit" to it. That said, including Mockito in this limited scope is a low-risk failsafe, IMO.
If you can update the client.xml with the same assembly descriptor change as hadoop-three-compat.xml has, I think your change is even better :).
trivially hbase org.apache.hadoop.hbase.IntegrationTestIngest
fails without this change and will run with it.
|
||
<!-- Adds junit libs to lib/test --> | ||
<dependencySet> | ||
<outputDirectory>lib/test</outputDirectory> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed this gets missed in the client tarball. Just copy this same block in hbase-assembly/src/main/assembly/client.xml
yeah that's fine by me. |
Thanks @joshelser @busbey and @ndimiduk ! Had pushed two additional commits, with updates to the ref-guide, adding mockito lib, and adding the test libs to the client tar ball. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting parity with the client tarball. LGTM
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have one concern with the mockito change. Everything else looks great.
pom.xml
Outdated
@@ -2491,7 +2491,6 @@ | |||
<groupId>org.mockito</groupId> | |||
<artifactId>mockito-core</artifactId> | |||
<version>${mockito-core.version}</version> | |||
<scope>test</scope> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should not remove scope:test
from this managedDependency
-- this definition is pulled into many many module. Instead, can you override the dependency scope in abase-assembly/pom.xml
to be scope:compile
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, that should have been with "request changes".
<dependency> | ||
<groupId>org.mockito</groupId> | ||
<artifactId>mockito-core</artifactId> | ||
<scope>compile</scope> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works? Great!
Because compile
is the default scope, someone later may be tempted to remove this distinction. Maybe add a comment to future do-gooders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
#4223) Signed-off-by: Josh Elser <elserj@apache.org> Singed-off-by: Nick Dimiduk <ndimiduk@apache.org> Reviewed-by: Sean Busbey <busbey@apache.org>
#4223) Signed-off-by: Josh Elser <elserj@apache.org> Singed-off-by: Nick Dimiduk <ndimiduk@apache.org> Reviewed-by: Sean Busbey <busbey@apache.org>
💔 -1 overall
This message was automatically generated. |
apache#4223) Signed-off-by: Josh Elser <elserj@apache.org> Singed-off-by: Nick Dimiduk <ndimiduk@apache.org> Reviewed-by: Sean Busbey <busbey@apache.org> (cherry-picked from commit 35868ab) Change-Id: I2c86f75549cad72755aafa7f3d9bd940cd241a06
…issues for some hbase tools that do rely on it