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

feat(codebuild): add support for GPU build images #8879

Merged
merged 11 commits into from Aug 12, 2020

Conversation

skinny85
Copy link
Contributor

@skinny85 skinny85 commented Jul 2, 2020

CodeBuild has added support for running builds on machines with GPU drivers.
This required some changes to the protocol between IBuildImage and Project,
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 to IBuildImage -
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

@skinny85 skinny85 requested a review from rix0rrr July 2, 2020 20:56
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jul 2, 2020
@rix0rrr rix0rrr added the pr/do-not-merge This PR should not be merged at this time. label Jul 7, 2020
Copy link
Contributor

@rix0rrr rix0rrr left a 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)

packages/@aws-cdk/aws-codebuild/lib/project.ts Outdated Show resolved Hide resolved
@@ -1138,6 +1139,24 @@ export interface BuildEnvironment {
readonly environmentVariables?: { [name: string]: BuildEnvironmentVariable };
}

/** Optional arguments to {@link IBuildImage.binder} - currently empty. */
export interface BuildImageBindOptions {}
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 this is fine to not put in. Adding optional arguments is not a breaking change.

Copy link
Contributor Author

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.

Copy link
Contributor

@rix0rrr rix0rrr Aug 10, 2020

Choose a reason for hiding this comment

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

Are ya sure?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

@skinny85 skinny85 Aug 10, 2020

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 ?

Copy link
Contributor

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 :)

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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, {});
Copy link
Contributor

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.

Copy link
Contributor Author

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": {
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 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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@skinny85
Copy link
Contributor Author

skinny85 commented Aug 8, 2020

@rix0rrr I've incorporated your comments, this is ready for another round of reviews.

Copy link
Contributor

@rix0rrr rix0rrr left a 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.

@skinny85 skinny85 removed the pr/do-not-merge This PR should not be merged at this time. label Aug 12, 2020
@mergify
Copy link
Contributor

mergify bot commented Aug 12, 2020

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).

@skinny85 skinny85 added the pr/do-not-merge This PR should not be merged at this time. label Aug 12, 2020
@skinny85 skinny85 removed the pr/do-not-merge This PR should not be merged at this time. label Aug 12, 2020
@mergify
Copy link
Contributor

mergify bot commented Aug 12, 2020

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: a20cfd4
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Aug 12, 2020

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).

@mergify mergify bot merged commit b1b4cee into aws:master Aug 12, 2020
@skinny85 skinny85 deleted the feat/codebuild-gpu-images branch August 12, 2020 22:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CodeBuild "LINUX_GPU_CONTAINER" environment type
4 participants