-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(codebuild): add support for GPU build images #8879
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.
Conditionally approved -- one rename, and one reorganization that I'm leaving to you whether you want to carry it out (but I dearly request you do)
6dab0bc
to
ff864ee
Compare
@@ -1138,6 +1139,24 @@ export interface BuildEnvironment { | |||
readonly environmentVariables?: { [name: string]: BuildEnvironmentVariable }; | |||
} | |||
|
|||
/** Optional arguments to {@link IBuildImage.binder} - currently empty. */ | |||
export interface BuildImageBindOptions {} |
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 this is fine to not put in. Adding optional arguments is not a breaking change.
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.
You cannot have optional arguments on interface declarations in TypeScript.
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.
Are ya sure?
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 that a jsii restriction? Seems to work fine:
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.
You're right, apologies. I was thinking about default arguments, not optional arguments.
But is adding an optional argument later really a backwards-compatible change? If I have:
export interface IBindableBuildImage extends IBuildImage {
bind(scope: Construct, project: IProject): BuildImageConfig;
}
and I later change it to:
export interface IBindableBuildImage extends IBuildImage {
bind(scope: Construct, project: IProject, options? BuildImageBindOptions): BuildImageConfig;
}
Won't that break, for example, Java implementations of IBindableBuildImage
?
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.
Hm. You might be right. Ask Romain, I guess :)
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.
So this won't break because:
- In Java we generate overload signatures by shaving the last optional argument until the last argument is no longer optional
- In C# we'll generate a signature with a default value (of
null
) for this argument, which reproduces the JS behavior - In Python we'll generate a signature with a default value (of
None
) for this argument, which reproduces the JS behavior
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.
Oh wait this is an interface... I'm not sure we generate default overrides on those (we could totally do it if we don't already).
EDIT: No we cannot make this non-breaking, because even if we introduce default overrides, existing code that implements only the override with fewer arguments won't implement the "new" form with one more parameter... #ouch
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.
That needs to be a jsii-diff issue then :(
@@ -796,6 +794,9 @@ export class Project extends ProjectBase { | |||
if (props.encryptionKey) { | |||
this.encryptionKey = props.encryptionKey; | |||
} | |||
|
|||
// bind | |||
this.buildImage.binder?.bind(this, this, {}); |
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.
How about getting as close as possible to the final desired state?
If there is a bind, call it, and the bind should return all the relevant image properties. Otherwise use the properties from the current class.
That, instead of mixing the two as is happening right 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.
I'm not sure I want to do that. That would mean a lot more complicated migration from 1.x
to 2.x
for users who have their own implementation of IBuildImage
.
} | ||
}, | ||
"Mappings": { | ||
"AwsDeepLearningContainersRepositoriesAccounts": { |
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 the better structure for this mapping is better to look something more like this:
Mappings: {
RegionInfo: {
us-east-1: {
dlcRepositoryAccount: 763104351884,
elbAccount: 12345768012,
cloudFrontHostedZoneId: AIJ35819Z
}
},
}
etc. I'm not looking forward to having a different mapping for every key, especially when mappings are already 2-level by default.
Means that there should be some RegionInfo helper that progressively adds facts to a global map if a new fact is required in an agnostic region. I will be frank that I'm not 100% sure where that helper should live. Does @aws-cdk/core
already depend on region-info
? If so, that might be a good place to put it.
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'm actually not sure about this. It would mean that everyone who uses just Deep Learning Containers will also get all information about ELB accounts, CloudFront hosted zone IDs, and a lot of different stuff they probably have zero interest in. This will:
a) make their template a lot bigger, and
b) as they upgrade their version of the CDK, every change to ELB accounts, CloudFront hosted zone IDs, etc. will result in a needless change to their CodeBuild template.
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.
Obviously I did not mean "just stuff all facts into a single static map that gets included into every template". Only the facts needed by the template should be in the map. To quote myself:
Means that there should be some RegionInfo helper that progressively adds facts to a global map if a new fact is required in an agnostic region.
On second thought, nevermind I guess. We will kick the can down the road and address this when we have 5 mappings.
ff864ee
to
0350376
Compare
@rix0rrr I've incorporated your comments, this is ready for another round of reviews. |
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.
Double check the optional argument please.
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from master 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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
CodeBuild has added support for running builds on machines with GPU drivers.
This required some changes to the protocol between
IBuildImage
andProject
,as those images are hosted in a public ECR repository that the image must grant the Project's Role access to.
Introduced a
bind()
method toIBuildImage
-to maintain backwards comaptibility,
made it optional.
Fixes #8408
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license