-
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
rfc: cdk-bootstrap
command
#4461
Conversation
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@eladb ping |
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 add
design/cdk-bootstrap.md
Outdated
|
||
* `--kms-key-id`, `-k`: optional identifier of the KMS key used for encrypting the file assets S3 bucket. | ||
|
||
These are the new 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.
No need to separate old and new
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 kind of like it. Makes it easy at a glance to see what is there because of backwards compatibility, and what we're adding.
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 can add a section in the end that describes the delta from the current experience.
* `--qualifier`, `-q`: an optional qualifier added to the physical names of the bootstrap resources | ||
in order to protect against name collisions, especially for things like S3 buckets | ||
(which are globally unique in a given AWS partition). | ||
|
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.
--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.
Can we not have it in V1?
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.
As we talked, we are not planning to implement a tool in v1, just a template and also not provide any degrees of freedom for names or keys or anything. This is the only customization hook and therefore it’s required for v1
design/cdk-bootstrap.md
Outdated
in order to protect against name collisions, especially for things like S3 buckets | ||
(which are globally unique in a given AWS partition). | ||
|
||
## Updating bootstrap resources |
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.
This is a really important topic, but we need to figure out a solution that can seamlessly work without our CI/CD story. Needs more thinking.
Did you not finish this sentence perhaps...? |
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 more I am thinking about this the more I realise that basically cdk-bootstrap
is just a CloudFormation template. All options should be expressed as CFN parameters with default values (besides the deployment managed policy name, which should be required). Then, users should be able to deploy these templates in any way they want - either through cdk-bootstrap
or through other means like StackSets.
5b872da
to
df50369
Compare
Incorporated the comments, and submitted a new revision. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
df50369
to
e71588b
Compare
New revision, incorporating the comments. BTW, I checked, and specifying multiple principals in the assume role policy document works as expected (IAM treats it as an 'OR', not an 'AND'). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 add a backwards compat section (derived from the main CI/CD backwards compat section). Since we should support both OLD and NEW bootstrap stacks, and we are going to remove a bunch of options, I am wondering if we should just create another CLI command cdk bootstrap-v2
or cdk boot
for the new bootstrap model. This way we don't have to maintain backwards compat on the API and this allows users to also decide if they want to use the old bootstrap stack or the new based on their use case.
I really don't like that. We are surfacing to the customers something that is an implementation detail of bootstrapping, and that they don't care about (I don't think anybody wants to learn the differences between the 2 bootstrap commands). In my opinion, we should actually strive to keep the existing command-line options, and make the transition as transparent to the customer as possible (for example, I would keep the same logical ID of the file assets bucket as the current bootstrap template, so that CFN recognizes them as the same resource). |
e71588b
to
ce9ba2d
Compare
Done in the newest revision. I definitely need your help in filling out the behavior for some of the rows, so if you could review that in detail, that would be great. Thanks! |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
I don't see how we can avoid supporting both old and new bootstrap stacks given our compatbility requirements. Do you have a better suggestion? |
In my opinion, we need to handle a very similar case anyway, so we might as well allow this. Imagine somebody deployed a custom CloudFormation template for bootstrapping instead of ours, and they gave the file asset bucket a specific name. However, they forgot to override the default settings when creating their If we have to handle that case anyway, then handling |
ce9ba2d
to
fac3160
Compare
Newest revision expands the "Backwards compatibility" section, and makes some changes to the template. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
some initial comments
|
||
* If the export value is larger than the `BOOTSTRAP_VERSION` constant in the current CLI, | ||
that means the bootstrap stack is actually from a later version than the used CLI version. | ||
In this case, I think it's correct to proceed with carrying out the operation; |
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 guess that means that all new versions must be backwards compatible, correct? Do we want semver instead of just a number then?
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.
Sure, that's a good idea.
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.
Actually, I don't know how should that work... what if the bootstrapped environment has version 1.2.0
, and the current CLI needs version 2.1.3
? What should happen?
Can you outline the cases, and what should be behavior be, in all the cases, like it is now for the monotonically increasing numbers?
cdk-bootstrap
command design documentcdk-bootstrap
command design document
cdk-bootstrap
command design documentcdk-bootstrap
command
fac3160
to
c1cfaa3
Compare
Published a new revision with the latest comments included, @eladb please re-review. Also, if you could address this comment that I made, that would be great. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 RFC is in a good state. There are a few things that we will probably tweak as we dive deeper into the implementation (I am still not 100% sure about how version checks will work in practice)
I don't think invoking the full `cdk-bootstrap` tool on every deploy is a good idea, though; | ||
I worry that calculating a full diff of actual versus desired resource state might impact the performance of commands like | ||
`deploy` too negatively. |
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.
This is also something we cannot do in the CI/CD scenario
Thank you for contributing! Your pull request is now being automatically merged. |
1 similar comment
Thank you for contributing! Your pull request is now being automatically merged. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
In the original RFC for the modified cdk bootstrap command done in aws#4461, we removed two options from the cdk bootstrap command-line utility: `--toolkit-bucket-name` and `--bootstrap-kms-key-id`. In this small revision to that RFC, I propose we not remove them to preserve backwards compatibility for customers who already use those options, and I show what changes that would require to our bootstrap CloudFormation template.
…5757) In the original RFC for the modified cdk bootstrap command done in #4461, we removed two options from the cdk bootstrap command-line utility: `--toolkit-bucket-name` and `--bootstrap-kms-key-id`. In this small revision to that RFC, I propose we not remove them to preserve backwards compatibility for customers who already use those options, and I show what changes that would require to our bootstrap CloudFormation template.
This is an RFC for an enhanced
cdk-bootstrap
command, as needed by our "Continuous Delivery for CDK apps" story.Related to #3437
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license