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 support for EIPs associated with secondary ENIs #1513

Merged
merged 8 commits into from
Nov 13, 2023

Conversation

brituck
Copy link

@brituck brituck commented Sep 14, 2023

Currently, Eureka client only supports registering EIPs that are directly associated to an instance and available via the root public-ipv4 IMDS key. This PR adds support to register an EIP that is attached via a secondary ENI. Due to the complexities of discovering and registering multiple public IPs for a single instance, we only register the first found public IP address. If an instance has both an EIP directly associated and and EIP associated via an ENI, the directly associated EIP will be registered. If the instance only has a EIP(s) associated via a ENI(s), the first found EIP will be registered. Additional use cases (i.e., registering multiple public IPv4 addresses) will not be supported.

@Netflix Netflix deleted a comment from error0702 Nov 9, 2023
@@ -76,7 +76,7 @@ public void testOnDemandUpdateRateLimiting() throws Throwable {
assertTrue(replicator.onDemandUpdate());
Thread.sleep(10); // give some time for execution
assertFalse(replicator.onDemandUpdate());
Thread.sleep(10);
Thread.sleep(1000);
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this flakey?

Copy link
Author

Choose a reason for hiding this comment

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

Yeah. I'm guessing both those onDemandUpdate() calls didn't have time to finish so the rate limiter counts never triggered. Increasing the sleep give them time to finish and the counter to increment.

@@ -89,7 +89,6 @@ public void testForceGzip() throws Exception {
@Test
public void testForceGzipOtherHeader() throws Exception {
noneGzipRequest();
when(request.getHeader("Test")).thenReturn("ok");
Copy link
Contributor

Choose a reason for hiding this comment

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

What changed here?

Copy link
Author

@brituck brituck Nov 9, 2023

Choose a reason for hiding this comment

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

Updating the Mockito version to 3.4.0 changes the strictness of mock checks. That call request.GetHeader("Test") was never called during the test so it fails with unnecessarystubbingexception. It's not necessary for the test so I removed it.

The update to Mockito 3.4.0 is necessary so I can mock the static function AmazonInfoUtils.readEc2MetadataUrl() in AmazonInfoTest. Without it this PR becomes much larger as I'd have to split out the AmazonInfoUtils into an interface which can then be mocked and add implementations where it's currently referenced.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why did the ClusterSampleData change?

Copy link
Author

@brituck brituck Nov 9, 2023

Choose a reason for hiding this comment

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

In the update to Mockito 3.4.0 the ArgumentMatcher for anyString() changed from accepting "any string or null" to "any string". In the testStatusUpdate() and testDeleteStatusOverride() tests in PeerReplicationResourceTest, the provided parameter for status in the downstream instanceResource.statusUpdate() call is null, which results in the Mock not matching and our response returning null.

There are two solutions to this:

  1. Refactor the fields in the returned ReplicationInstance (current change in this PR) to correctly capture the intent of the statusUpdate() and deleteStatusUpdate() calls.

    The current master branch calls statusUpdate(String newStatus = null, String isReplication = "true", String lastDirtyTimestamp = "12345678") and deleteStatusUpdate(String isReplication = "true", String newStatus = null, String lastDirtyTimestamp = "12345678"), which to me seems odd that we'd set newStatus = null in each rather than an actual status.
  2. Change the mock expression for statusUpdate() and deleteStatusUpdate() to isNull() for the parameters that return null.

I prefer the first option as I believe it's the more correct change, but I'm happy to go with 2) if we want to minimize the changes in this PR.

@drobertduke drobertduke merged commit bae5c36 into master Nov 13, 2023
1 check passed
@drobertduke drobertduke deleted the feature/eni-eips branch November 13, 2023 18:29
joshgord pushed a commit that referenced this pull request Nov 29, 2023
Add support for EIPs associated with secondary ENIs
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