Adds a basic sanity test to run against a remote cluster

[DarshitChanpura]

Description

Adds a new feature as an enhancement to existing test framework, which enables security to run integration tests against a remote cluster

• Category : Enhancement
• Why these changes are required? : To enable security to run tests with distribution build

Related Issues:

#1761

Testing

Integration test

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov-commenter]

Codecov Report

Merging #1958 (6d6fd75) into main (437eb02) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1958      +/-   ##
============================================
- Coverage     61.05%   61.04%   -0.02%     
  Complexity     3233     3233              
============================================
  Files           256      256              
  Lines         18085    18085              
  Branches       3222     3222              
============================================
- Hits          11042    11040       -2     
- Misses         5467     5470       +3     
+ Partials       1576     1575       -1     

Impacted Files	Coverage Δ
...ecurity/configuration/StaticResourceException.java	0.00% <0.00%> (-25.00%)	⬇️
...nsearch/security/dlic/rest/api/AuditApiAction.java	63.82% <0.00%> (-4.26%)	⬇️
...a/org/opensearch/security/tools/SecurityAdmin.java	37.56% <0.00%> (+0.24%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[saratvemulapalli]

Overall the changes are good. Lets take a test dependency on common-utils instead.

[saratvemulapalli]

Overall the changes look good to me.

Dropped a tiny comment.

[saratvemulapalli]

Same here, add common-utils version as a property.
Also check if opensearch build systems can send out common-utils version.

[DarshitChanpura]

It isn't part of version.properties. Should we add it there? I'm not sure about other ways it can be passed. I looked around but couldn't find any reference

[peternied]

Can we add a CI task to run these tests on pull requests to be sure these are operational?

[DarshitChanpura]

Can we add a CI task to run these tests on pull requests to be sure these are operational?

Done. Added it as a task to plugin_install CI check

[DarshitChanpura]

The CI checks are failing after incrementing main to version 2.2.0.0 because it is now expecting to find common-utils with version 2.2.0.0

Execution failed for task ':compileTestJava'.
> Could not resolve all files for configuration ':testCompileClasspath'.
   > Could not resolve org.opensearch:common-utils:2.2.0.0.
     Required by:
         project :
      > Could not resolve org.opensearch:common-utils:2.2.0.0.
         > Could not get resource 'https://d1nvenhzbhpy0q.cloudfront.net/snapshots/lucene/org/opensearch/common-utils/2.2.0.0/common-utils-2.2.0.0.pom'.
            > Could not GET 'https://d1nvenhzbhpy0q.cloudfront.net/snapshots/lucene/org/opensearch/common-utils/2.2.0.0/common-utils-2.2.0.0.pom'. Received status code 403 from server: Forbidden

I would suggest to hard-code the common-utils version in build.gradle as we are also referencing SecureRestClientBuilder class to create a secure client, in addition to referring to the constants.
OR
We can wait until common-utils updates its version to 2.2.0.0 before running CI checks on this PR.

[peternied]

hard-code the common-utils version in build.gradle

I think this is the easiest way to keep moving forward, but please create a bug in common-utils to track this. It seems like the dependencies we've taken on should be inside of OpenSearch's core repo

[DarshitChanpura]

Here is the tracking issue in common-utils repository: opensearch-project/common-utils#205

[DarshitChanpura]

Here is the tracking issue in common-utils repository: opensearch-project/common-utils#205

Following the comment in the tracking issue, hard-coded reference to common-utils will need to be updated to fetch dynamically once it publishes the latest version.

[DarshitChanpura]

Local debugging of CI task bwc-test failure errors out with java.lang.NoSuchMethodError: 'org.gradle.internal.resources.ResourceLock org.gradle.internal.resources.SharedResource.getResourceLock(int)'

This error occurs after upgrading gradle to 7.5 and is worked on in the core and a fix has been addressed here

[peternied]

@DarshitChanpura Anything you need help with to get this ready for merging?

[DarshitChanpura]

Bwc test CI run fails with :

Execution failed for task ':securityBwcCluster#oldVersionClusterTask1'.
> No tests found for given includes: [**/*$*.class, **/*Test*](exclude rules)

but local skips bwc tests with NO SOURCE:

2022-08-01T12:48:34.984-0400 [DEBUG] [org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter] Putting task artifact state for task ':securityBwcCluster#fullRestartClusterTask' into context took 0.0 secs.
2022-08-01T12:48:34.987-0400 [INFO] [org.gradle.internal.execution.steps.SkipEmptyWorkStep] Skipping task ':securityBwcCluster#fullRestartClusterTask' as it has no source files and no previous output files.

Any ideas on how to solve this?

[peternied]

local skips bwc tests with NO SOURCE:

When you run gradle add the --rerun-tasks flag to force gradle to execute the task, docs.

[DarshitChanpura]

local skips bwc tests with NO SOURCE:

When you run gradle add the --rerun-tasks flag to force gradle to execute the task, docs.

added it, still the same result. I think it has something to do with the filter to exclude tests

[DarshitChanpura]

I tried to print System properties to see whether these type of if condition will be successfull, turns out it isn't and hence the task isn't able to find any tests classes to test

[DarshitChanpura]

I tried to print System properties to see whether these type of if condition will be successfull, turns out it isn't and hence the task isn't able to find any tests classes to test

I was able to replicate it on my local machine.

[opensearch-trigger-bot]

The backport to 1.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.x 1.x
# Navigate to the new working tree
cd .worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-1958-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 f7b6fe588f0eb44c1767b8b6c00ca0bf3f121606
# Push it to GitHub
git push --set-upstream origin backport/backport-1958-to-1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.x

Then, create a pull request where the base branch is 1.x and the compare/head branch is backport/backport-1958-to-1.x.

[opensearch-trigger-bot]

The backport to 1.3 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.3 1.3
# Navigate to the new working tree
cd .worktrees/backport-1.3
# Create a new branch
git switch --create backport/backport-1958-to-1.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 f7b6fe588f0eb44c1767b8b6c00ca0bf3f121606
# Push it to GitHub
git push --set-upstream origin backport/backport-1958-to-1.3
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.3

Then, create a pull request where the base branch is 1.3 and the compare/head branch is backport/backport-1958-to-1.3.