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

Mimic storage notifications using the HTTP API #1339

Merged
merged 4 commits into from
Aug 28, 2023

Conversation

burmanm
Copy link
Collaborator

@burmanm burmanm commented Aug 10, 2023

This branch is based on the PR #1336

@github-actions
Copy link

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

Copy link
Contributor

@Miles-Garnsey Miles-Garnsey left a comment

Choose a reason for hiding this comment

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

Thanks for this @burmanm, it is good to see how your proposed notifications mechanism might work!

One Issue: can we possibly start putting some unit tests into this PR? I know higher level tests won't pass because we don't yet have the work done on management API, but it would be good to see unit tests if possible.

I've left a number of other comments (mostly questions) throughout the code. I'll also continue reading through to try to better understand how this will work.

Perhaps it will be clearer to me once some of the mgmt API stuff is complete and we can start to see the integration between the two more clearly.

@burmanm burmanm changed the base branch from master to integration/http-managementproxy August 22, 2023 14:06
@burmanm burmanm marked this pull request as ready for review August 22, 2023 14:06
…ork without the actual client implementation

Implement using apiClient the triggerRepair, getJobDetails, scheduler as well as add a simple test to ensure the state is managed correctly
Copy link
Contributor

@Miles-Garnsey Miles-Garnsey left a comment

Choose a reason for hiding this comment

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

Here's a preliminary review, I'm still working through this as I've been trying to get my PR merged today. I think maybe some more tests might be good, but not sure how hard they might be to implement given all of the concurrency stuff you have here.

@@ -1,5 +1,5 @@
/*
* Copyright 2020-2020 The Last Pickle Ltd
* Copyright 2023-2023 DataStax, Inc.
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm, I think this should be

 * Copyright 2020-2022 The Last Pickle Ltd
 * Copyright 2023 DataStax, Inc.

But I'm not a lawyer.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Checkstyle won't accept that format. In any case, this type of copyright info is not necessary in EU at least.

Copy link
Contributor

Choose a reason for hiding this comment

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

Same in AU, but we need to consider US.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well, then that would be outside PR which would modify the checkstyle and copyright creation in the project. Right now the years are all over the place in every file.

RepairParallelism.PARALLEL,
Collections.singleton("table"), true, Collections.emptyList(), repairStatusHandler, Collections.emptyList(), 1);

assertEquals(123456789, repairNo);
Copy link
Contributor

Choose a reason for hiding this comment

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

Issue: can we make some assertions around which functions have been called and how many times?

Copy link
Contributor

Choose a reason for hiding this comment

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

Issue: can we please test the individual methods here? And also look at what happens under failure conditions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Issue: can we make some assertions around which functions have been called and how many times?

Done in the next test. It's not what this test would test as it doesn't care if any method is called. This is intended to test that the maps have correct amount of entries (if someone refactors the repair endpoint for example, but forgets to insert correct places, then this test would fail and tell that info).

Issue: can we please test the individual methods here? And also look at what happens under failure conditions?

This is already calling the individual methods. triggerRepair & removeRepairStatusHandlers are the interesting methods this one calls directly.


RepairStatusHandler repairStatusHandler = Mockito.mock(RepairStatusHandler.class);

int repairNo = httpCassandraManagementProxy.triggerRepair(BigInteger.ZERO, BigInteger.ONE, "ks",
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: can we figure out whether the beginToken/endToken is still the right way to call this function? From what I could see it seemed like the current underlying JMX call actually uses the RingRange, but I'd have to go back to confirm how this works.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Isn't that part of your PR? In this test those values mean nothing, they're simply ignored.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it only applies to Cassandra < 2.2 from memory, that's why I'm wondering if it is a good idea to merge this now, since additional work might yield a slightly different solution for parts of this PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I mean this PR doesn't care even if it's triggerRepair() and no parameters at all. That has no impact to functionality here.

Copy link
Contributor

@Miles-Garnsey Miles-Garnsey left a comment

Choose a reason for hiding this comment

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

Three comments to address, otherwise good to merge to the integration branch!

}

@VisibleForTesting
private void scheduleJobPoller(ScheduledExecutorService scheduler, int pollInterval) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove this ScheduledExecutorService argument and call this.scheduler?

@@ -83,4 +109,98 @@ private <T extends Object> T jsonFromResourceFile(String filename, Class<T> claz
return new ObjectMapper().readValue(
this.getClass().getResource(filename).openStream(), clazz);
}

@Test
public void testRepairHandlers() throws Exception {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe consider more descriptive names for tests?

RepairStatusHandler workAroundHandler = (repairNumber, status, progress, message, cassandraManagementProxy)
-> callTimes.incrementAndGet();

// RepairStatusHandler repairStatusHandler = mock(RepairStatusHandler.class);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove comment.

@burmanm burmanm merged commit e5bbf2f into integration/http-managementproxy Aug 28, 2023
2 checks passed
@adejanovski adejanovski linked an issue Aug 29, 2023 that may be closed by this pull request
4 tasks
adejanovski pushed a commit that referenced this pull request Sep 6, 2023
* Add stubbed polling of job details from the mgmt-api. This will not work without the actual client implementation

Implement using apiClient the triggerRepair, getJobDetails, scheduler as well as add a simple test to ensure the state is managed correctly

* Merge test files after the rebase

* Add a test to verify the behavior of the notifications polling

* Address comments
Miles-Garnsey pushed a commit that referenced this pull request Oct 3, 2023
* Add stubbed polling of job details from the mgmt-api. This will not work without the actual client implementation

Implement using apiClient the triggerRepair, getJobDetails, scheduler as well as add a simple test to ensure the state is managed correctly

* Merge test files after the rebase

* Add a test to verify the behavior of the notifications polling

* Address comments
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.

Ensure Reaper can call the new Management API async notifications endpoints
2 participants