-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(opensearchservice): nodeoptions for domain #32936
Conversation
### Reason for this change Introduced new interfaces and validation for configuring coordinator nodes in OpenSearch domains, allowing users to specify node options such as instance type and count. ### Description of changes - Added `NodeOptions` and `NodeConfig` interfaces to define configurations for coordinator nodes. - Updated the `Domain` class to handle `nodeOptions` in the capacity configuration, including validation for instance type and count. - Enhanced unit tests to cover new configurations and validation scenarios for coordinator nodes. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
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.
👍 Left some comments for adjustments
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.
Thank you for contributing, just a few clarifying questions.
/** | ||
* Configuration for the node type | ||
*/ | ||
readonly nodeConfig: NodeConfig; |
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.
Does this need to be a required property when the inner properties are all optional?
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.
Can we rely on the backend to respond to this one? Meaning right now we have a logic on what is required.
eg - if enabled = true, then we need to pass type and count, if enabled = false, type and count become optional.
Will keep this logic as it as is for now.
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.
Not sure how this is related to the backend.
This is a pretty nit comment anyway: I'm mainly talking about the usage like below. Since the properties of NodeConfig
are all optional, we can make nodeConfig
an optional property as well so users are not limited to
{
nodeType: someType,
nodeConfig: {}
}
and can also simplify this to below
{
nodeType: someType,
}
const coordinatorConfig = props.capacity.nodeOptions.find(opt => opt.nodeType === NodeType.COORDINATOR)?.nodeConfig; | ||
if (coordinatorConfig?.enabled) { | ||
const coordinatorType = initializeInstanceType(defaultCoordinatorInstanceType, coordinatorConfig.type); | ||
if (!cdk.Token.isUnresolved(coordinatorType) && !coordinatorType.endsWith('.search')) { |
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.
is the unresolved token check needed as initializeInstanceType
has done the check.
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.
Followed the same as it was for warm, data, master. Can you please check
@@ -1863,6 +1923,20 @@ export class Domain extends DomainBase implements IDomain, ec2.IConnectable { | |||
this.validateSamlAuthenticationOptions(props.fineGrainedAccessControl?.samlAuthenticationOptions); | |||
} | |||
|
|||
if (props.capacity?.nodeOptions) { | |||
// Validate coordinator node configuration | |||
const coordinatorConfig = props.capacity.nodeOptions.find(opt => opt.nodeType === NodeType.COORDINATOR)?.nodeConfig; |
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 find
only returns the first matching item, what about the rest, are we going to do validation?
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.
We can't have more than one nodeConfig object for a single node type
@@ -2676,3 +2676,94 @@ function testMetric( | |||
}); | |||
expect(metric.dimensions).toHaveProperty('DomainName'); | |||
} | |||
|
|||
each(testedOpenSearchVersions).test('can configure coordinator nodes with nodeOptions', (engineVersion) => { |
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.
can you add a test case where we have two NodeOptions items and the second one is has invalid type that doesn't end with .search
.
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.
We can't have two nodeoptions of same node type. The backend have checks for that and will throw error.
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This pull request has been removed from the queue for the following reason: The pull request can't be updated You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32936 +/- ##
=======================================
Coverage 82.21% 82.21%
=======================================
Files 119 119
Lines 6876 6876
Branches 1162 1162
=======================================
Hits 5653 5653
Misses 1120 1120
Partials 103 103
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #32553.
Reason for this change
#32553.
Recently as a part of coordinator node project we introduced a new parameter called NodeOptions, currently its part of L1 construct but we wanted it to be part of L2 construct and that is why raising this PR.
Description of changes
The code is very much similar to - #28497 and follows all standard practices in the repository.
Describe any new or updated permissions being added
N/A
Description of how you validated changes
Unit tests -
Integration Tests -
Snapshots is also generated as a part of integration tests
Checklist
YES
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license