Skip to content
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

Add endpoints and authentication details (including SigV4) as parameters to E2E test script #461

Merged
merged 12 commits into from
Jan 11, 2024

Conversation

okhasawn
Copy link
Contributor

@okhasawn okhasawn commented Nov 30, 2023

Description

This PR adds the ability to provide the endpoints and authentication details as parameters to the test script.
The end goal is to be able to provide either local or cloud based endpoints as parameters and the authentication details as parameters and have the E2E test script run successfully.
This PR also enables to the E2E test script to run on endpoints that use SigV4.

Issues Resolved

Migrations-1442

Check List

  • New functionality includes testing
    • All tests pass, including unit test, integration test and doctest
  • 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.

Copy link

codecov bot commented Nov 30, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (c14529b) 77.08% compared to head (c7c1da3) 73.51%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #461      +/-   ##
============================================
- Coverage     77.08%   73.51%   -3.58%     
+ Complexity     1183     1180       -3     
============================================
  Files           149      124      -25     
  Lines          6041     4886    -1155     
  Branches        561      439     -122     
============================================
- Hits           4657     3592    -1065     
+ Misses         1076      999      -77     
+ Partials        308      295      -13     
Flag Coverage Δ
unittests 73.51% <ø> (-0.17%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@okhasawn okhasawn marked this pull request as ready for review December 4, 2023 18:34
@okhasawn okhasawn changed the title [WIP - Do Not Merge] Add endpoints and authentication details as parameters to E2E test script Add endpoints and authentication details as parameters to E2E test script Dec 4, 2023
Copy link
Collaborator

@lewijacn lewijacn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as this structure for local runs I only have one comment that I added. If we want this PR to be just for local I can go ahead and approve.

As far as running this on AWS it seems we still need a couple things, but correct me if I'm wrong

  1. Support for AWS SigV4 to verify clusters which have SigV4 enabled
  2. A mechanism to only run certains tests depending on some input parameter e.g. I only want to run sigv4 tests on AWS.
  3. Make sure existing test cases work for both local and AWS, I believe only test_0006_OSB needs to be tweaked but didn't check closely

@@ -44,4 +44,4 @@ jobs:
run: |
cd test
chmod +x ./tests.py
pytest -n 3 tests.py
pytest tests.py --proxy_endpoint="https://localhost:9200" --source_endpoint="https://localhost:19200" --target_endpoint="https://localhost:29200" --source_auth_type="basic" --source_username="admin" --source_password="admin" --target_auth_type="basic" --target_username="admin" --target_password="admin" --source_verify_ssl=False --target_verify_ssl=False
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't these all defaults, do we need to specify?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add the --verbose flag to this command. Some of these tests take a while to run so you start to wonder if things are working with no output. This flag will show each test as it gets started running

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I don't need to specify those in the workflow anymore. I had updated the defaults value after.
I'll update this to remove the values and add the verbose flag. Thank you!

self.assertEqual(response.status_code, HTTPStatus.METHOD_NOT_ALLOWED)

def test_0007_OSB(self):
def test_0006_OSB(self):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it will need to be tweaked to work for AWS as well. For AWS we will already be on the migration console box so we would just need to make the runTestBenchmarks.sh call from the right directory

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, this specific test won't work on AWS as of this moment. I imagined that this script will end up existing on the migration console and running from there. I can update this test in a future PR to support that.
As for the other tests; per my testing on our deployed AWS solution (w/o SigV4 whatsoever), they will pass.

@okhasawn
Copy link
Contributor Author

Thank you for reviewing!
As for your comments:

  • SigV4 support will be added in a future PR.
  • Certain tests can be ran using pytest's method of running tests which is for example: pytest tests.py::E2ETests::test_0001_index tests.py::E2ETests::test_0002_document will get this to only run those two tests specified.
  • You're right, existing tests will work except for the one you mentioned. I'll add a flag to check if it's running on AWS in this PR to exclude this test for now, and update this test to work on AWS in a future PR as well.

@okhasawn
Copy link
Contributor Author

okhasawn commented Jan 3, 2024

Added option to run on SigV4 enabled endpoints.

@okhasawn okhasawn changed the title Add endpoints and authentication details as parameters to E2E test script Add endpoints and authentication details (including SigV4) as parameters to E2E test script Jan 3, 2024
Copy link
Collaborator

@lewijacn lewijacn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm we still have the one test that won't work for both AWS and local, seems like we need some pattern in place so that only proper tests will run when this test script is executed



def create_index(endpoint: str, index_name: str, auth: Optional[Tuple[str, str]] = None, verify_ssl: bool = False):
def create_index(endpoint: str, index_name: str, auth, verify_ssl: bool = False, protocol: str = 'https'):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is the protocol argument being used in these methods? And why do only some methods have?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove this. Mistakenly added from something else I was testing.

@@ -8,3 +8,5 @@ pytest==7.3.1
pytest-xdist==3.3.1
requests==2.31.0
urllib3==2.0.7
requests_aws4auth
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this what FetchMigration uses as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, although one has a "-" and the other has a "_", but they're the exact same.



def create_index(endpoint: str, index_name: str, auth: Optional[Tuple[str, str]] = None, verify_ssl: bool = False):
def create_index(endpoint: str, index_name: str, auth, verify_ssl: bool = False, protocol: str = 'https'):
response = requests.put(f'{endpoint}/{index_name}', auth=auth, verify=verify_ssl)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the requests library is smart enough to see if it has basic or sigv4 auth passed to it and parse accordingly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct!

test/tests.py Outdated
cmd_exec = f"docker exec {container_id} ./runTestBenchmarks.sh"
logger.warning(f"Running command: {cmd_exec}")
if self.deployment_type == "cloud":
cmd_exec = f"./runTestBenchmarks --unique-id {self.index}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path here for runTestBenchmarks will be in a different directory. It's probably easiest to use /root/runTestBenchmarks.sh

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we also use the self.unique_id instead of self.index here? It seems like it may be clearer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, I'll update in the next commit.

test/tests.py Outdated
@@ -103,7 +104,7 @@ def setup_authentication(self, auth_type, username, password):
return None

def set_common_values(self):
self.index = f"my_index_{uuid.uuid4()}"
self.index = self.unique_id
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like it would be nice to keep the previous format like: f"test_index_{self.unique_id}" to be able to clearly tell what our test index is

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine our unique id for the integ tests may just be the name of the test and the pipeline run number like full_run_21

Signed-off-by: Omar Khasawneh <[email protected]>
@okhasawn okhasawn merged commit 75ff259 into opensearch-project:main Jan 11, 2024
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants