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

rfc: cdk-bootstrap command #4461

Merged
merged 7 commits into from
Nov 27, 2019
Merged

rfc: cdk-bootstrap command #4461

merged 7 commits into from
Nov 27, 2019

Conversation

skinny85
Copy link
Contributor

@skinny85 skinny85 commented Oct 10, 2019

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

@skinny85 skinny85 requested a review from eladb October 10, 2019 22:06
@mergify
Copy link
Contributor

mergify bot commented Oct 10, 2019

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
merged. In the meantime, please take a minute to make sure you follow this
checklist
:

  • PR title type(scope): text
    • type: fix, feat, refactor go into CHANGELOG, chore is hidden
    • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
    • text: use all lower-case, do not end with a period, do not include issue refs
  • PR Description
    • Rationale: describe rationale of change and approach taken
    • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
    • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
  • Testing
    • Unit test added. Prefer to add a new test rather than modify existing tests
    • CLI or init templates change? Re-run/add CLI integration tests
  • Documentation
    • README: update module README to describe new features
    • API docs: public APIs must be documented. Copy from official AWS docs when possible
    • Design: for significant features, follow design process

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@SomayaB SomayaB added the contribution/core This is a PR that came from AWS. label Oct 11, 2019
@skinny85 skinny85 assigned skinny85 and unassigned shivlaks Oct 12, 2019
@skinny85
Copy link
Contributor Author

@eladb ping

Copy link
Contributor

@eladb eladb left a comment

Choose a reason for hiding this comment

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

Please add


* `--kms-key-id`, `-k`: optional identifier of the KMS key used for encrypting the file assets S3 bucket.

These are the new options:
Copy link
Contributor

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

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 kind of like it. Makes it easy at a glance to see what is there because of backwards compatibility, and what we're adding.

Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

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

--template

Copy link
Contributor Author

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?

Copy link
Contributor

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

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
Copy link
Contributor

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.

@skinny85
Copy link
Contributor Author

Please add

Did you not finish this sentence perhaps...?

Copy link
Contributor

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

@skinny85
Copy link
Contributor Author

Incorporated the comments, and submitted a new revision.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@skinny85
Copy link
Contributor Author

skinny85 commented Nov 2, 2019

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

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

Copy link
Contributor

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

@skinny85
Copy link
Contributor Author

skinny85 commented Nov 5, 2019

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

@skinny85
Copy link
Contributor Author

skinny85 commented Nov 5, 2019

Please add a backwards compat section (derived from the main CI/CD backwards compat section).

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

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@eladb
Copy link
Contributor

eladb commented Nov 5, 2019

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

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?

@skinny85
Copy link
Contributor Author

skinny85 commented Nov 5, 2019

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

I don't see how we can avoid supporting both old and new bootstrap stacks given our compatibility 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 Stack classes. Obviously, this is an error, and we should have code in commands like cdk deploy and cdk publish that checks whether the bucket/ECR repository that the assets are supposed land in exist, and print a useful error message if not (for example: we can check whether the name is our "standard" name, and then differentiate between the cases when bootstrap was not run at all, or when bootstrap was customized).

If we have to handle that case anyway, then handling cdk bootstrap --trust 123456789012 --bootstrap-bucket-name my-bucket seems doable.

@skinny85
Copy link
Contributor Author

skinny85 commented Nov 5, 2019

Newest revision expands the "Backwards compatibility" section, and makes some changes to the template.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

Copy link
Contributor

@eladb eladb left a 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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

@eladb eladb added the management/rfc request for comments label Nov 13, 2019
@eladb eladb changed the title feat: cdk-bootstrap command design document rfc: cdk-bootstrap command design document Nov 13, 2019
@eladb eladb changed the title rfc: cdk-bootstrap command design document rfc: cdk-bootstrap command Nov 13, 2019
@skinny85 skinny85 requested a review from a team November 15, 2019 19:25
@skinny85
Copy link
Contributor Author

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

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

Copy link
Contributor

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

Comment on lines +140 to +142
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.
Copy link
Contributor

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

@mergify
Copy link
Contributor

mergify bot commented Nov 27, 2019

Thank you for contributing! Your pull request is now being automatically merged.

1 similar comment
@mergify
Copy link
Contributor

mergify bot commented Nov 27, 2019

Thank you for contributing! Your pull request is now being automatically merged.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@mergify mergify bot merged commit e9f282b into aws:master Nov 27, 2019
@skinny85 skinny85 deleted the rfc/cdk-bootstrap branch November 27, 2019 18:09
@eladb eladb mentioned this pull request Jan 15, 2020
2 tasks
skinny85 added a commit to skinny85/aws-cdk that referenced this pull request Mar 17, 2020
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.
skinny85 added a commit that referenced this pull request Mar 17, 2020
…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.
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. management/rfc request for comments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants