-
Notifications
You must be signed in to change notification settings - Fork 206
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
New Decorator for Architecture Type for all Addons and Graviton Builder Classes && Gen AI Builder and Team #846
Conversation
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.
@elamaran11 great effort and there is some work we should perform before exposing it to the customers. Please see my comments.
lib/builders/graviton-builder.ts
Outdated
version: options.kubernetesVersion, | ||
instanceTypes: [new ec2.InstanceType(`${options.instanceClass}.${options.instanceSize}`)], | ||
amiType: eks.NodegroupAmiType.AL2_ARM_64, | ||
desiredSize: 3, |
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.
If we are to move it beyond just a demo, these should be configurable. We need to add something like withNodeGroupOptions(options: Partial<ManagedNodeGroupProps>)
to the builder to allow any kind of an override. The approach is similar to the one I recommended to Bhavye on his builder.
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.
Why desiredSize, min, max
are left hardcoded and not leveraging the potentially passed value from the options?
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.
My recommendation is to use default MngClusterProviderProps and overwrite them with the supplied. That will be easier to implement and provides the best flexibility. In the current implementation it is more of a demo rather than a production ready builder.
lib/builders/genai-builder.ts
Outdated
import { NestedStack, NestedStackProps } from 'aws-cdk-lib'; | ||
import { Construct } from 'constructs'; | ||
|
||
export class GenAIBuilder extends BlueprintBuilder { |
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 am unclear on what specifically makes this builder a GenAI builder other than usage tracking? Is there anything that we should add specific to genAI like enable a particular instance types or deploy an example workload - something?
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.
Looks great. Some comments.
Please also run make lint
- there are many warnings
Fixed all issues pointed in this iteration. |
@shapirov103 All issues fixed. |
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.
@elamaran11 looking great. A couple of comments left, please take a look.
@shapirov103 Agreed to the comment, fixed it. Please take a look.
lib/builders/graviton-builder.ts
Outdated
version: options.kubernetesVersion, | ||
instanceTypes: [new ec2.InstanceType(`${options.instanceClass}.${options.instanceSize}`)], | ||
amiType: eks.NodegroupAmiType.AL2_ARM_64, | ||
desiredSize: 3, |
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.
Why desiredSize, min, max
are left hardcoded and not leveraging the potentially passed value from the options?
lib/builders/graviton-builder.ts
Outdated
version: options.kubernetesVersion, | ||
instanceTypes: [new ec2.InstanceType(`${options.instanceClass}.${options.instanceSize}`)], | ||
amiType: eks.NodegroupAmiType.AL2_ARM_64, | ||
desiredSize: 3, |
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.
My recommendation is to use default MngClusterProviderProps and overwrite them with the supplied. That will be easier to implement and provides the best flexibility. In the current implementation it is more of a demo rather than a production ready builder.
@shapirov103 Added Gen AI Class and Team. Please check the approach |
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.
A couple of high level comments for now on the GenAI design.
lib/teams/geneai-team/genai-team.ts
Outdated
*Sets IRSA for access to bedrock with required IAM policy along with creating a namespace. | ||
*/ | ||
|
||
export class GenAITeam extends ApplicationTeam { |
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.
since it is only setting up bedrock access, should we rename it to bedrock access or something more specific to the use case? We will have a bunch of genAI services right after RI, so we will have to eventually support them as well and it sounds like it will be a separate team per service?
lib/teams/geneai-team/genai-team.ts
Outdated
this.genAITeam = props; | ||
} | ||
|
||
setup(clusterInfo: ClusterInfo): void { |
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 it work? I see this code will clash with the setupServiceAccount method from the application team. I don't think you need to set it up like this at all. All you need to do is pass the serviceaccountname and serviceAccountPolicies to with the props to the Application team and its default setup method should take care of the IRSA stuff.
@shapirov103 PR is updated with |
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.
Please see my comment
* This method helps you prepare a blueprint for setting up EKS cluster with | ||
* usage tracking addon | ||
*/ | ||
public static builder(): BedrockBuilder { |
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.
aren't we supposed to add a bedrock team here ootb? e.g. take those props with the function and add the team. Or another alternative is to add a method like addBedrockTeam() to make it explicit.
The way it stands now, there is no differentiator for this builder for the customers.
@shapirov103 Makesense and i missed this, i fixed it now and all good. Please check and run e2e. |
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.
One small comment.
because of the quite significant surface area of chages, please test with patterns. Does it work for make test-all?
lib/utils/architecture-utils.ts
Outdated
function addAddonArch(addonName: string, architecture: ArchType) { | ||
if (addonArchitectureMap.has(addonName)) { | ||
const value = addonArchitectureMap.get(addonName); | ||
if (value !== undefined) { |
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.
Based on my observation:
this code when executed multiple times will keep adding supported archs to the global array. So if in my app I instantiate an addon 100 times, this will have at least 100 entries.
Let's add a check to add value only if it is not already there.
/do-e2e-tests |
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.
end to end tests passed
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.
LGTM - great work!
Issue #, if available:
Description of changes:
Generative AI and Graviton Builder Classes
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.