AWS CDK RFCs
This repo is a place to propose and track major upcoming changes to AWS CDK, jsii, andother related projects. It also is a great place to learn about the current andfuture state of the libraries and to discover projects for contribution.
Jump to: What is an RFC? |When to submit? |RFC Process |RFC Life Cycle
What is an RFC?
An RFC is a document that proposes a change to one of the projects led by theCDK team at AWS. Request for Comments means a request for discussion andoversight about the future of the project from maintainers, contributors andusers.
When should I write an RFC? The CDK team proactively decides to write RFCson major features or complex changes that we feel require that extra vetting.However, the process is designed to be as lightweight as needed and can be usedto request feedback on any change. Quite often, even changes that seem obviousand simple at first sight can be significantly improved once a wider group ofinterested and experienced people have a chance to weigh in.
Who should submit an RFC? An RFC can be submitted by anyone. In most cases,RFCs are authored by CDK maintainers, but contributors are more than welcome tosubmit RFCs.
If you are a contributor and you wish to write an RFC, please contact thecore team at the #aws-cdk-rfcs to make sure someone from the core team cansponsor your work. Otherwise, there is a good chance we won't have bandwidth tohelp.
RFC Process
To start an RFC process, create a new tracking issue and follow theinstructions in the issue template. It includes a checklist of the variousstages an RFC goes through.
This section describes each stage in detail, so you can refer to it forguidance.
1. Tracking Issue
Each RFC has a GitHub issue which tracks it from start to finish. The issue isthe hub for conversations, community signal (+1s) and the issue number is usedas the unique identifier of this RFC.
Before creating a tracking issue, please search for similar or related ideas inthe RFC table above or in the issue list of this repo. If there is a relevantRFC, collaborate on that existing RFC, based on its current stage.
Our tracking issue template includes a checklist of all the steps an RFC goesthrough and it's the driver's responsibility to update the checklist and assignthe correct label to on the RFC throughout the process.
When the issue is created, it is required to fill in the following information:
- Title: the name of the feature or change - think changelog entry.
- Description: a short description of feature, as if it was already implemented.
- Proposed by: fill in the GitHub alias of the person who proposed the ideaunder "Proposed by".
2. API Bar Raiser
Reach us via #aws-cdk-rfcs to get an "API Bar Raiser" assigned to your RFC.
For each RFC, CDK leadership will assign an API Bar Raiser who reviews andapproves the public API of the feature. API Bar Raisers have veto rights onAPI-related design decisions, such as naming, structure, options, CLI commandsand others.
The public API of a feature represents the surface through which users interactwith it, and we want to make sure these APIs are consistent, ergonomic anddesigned based on the intent and the mental model of our users. Additionally,once we announce that a feature is "stable" (1.0, GA, etc) any breaking changeto its public API will require releasing a new major version, so we like thinkof API decisions as "one way doors".
API Bar Raisers will be assigned using a tiering model which is generally basedon the size of the user base that will likely get exposed to the feature. As ageneral rule, the more "significant" the feature is, we will assign a bar raiserwith a wider and longer-term context of the project.
To merge an RFC, a sign-off from the bar raiser is requiredon the public API of the feature, so we encourage to engage with them early inthe process to make sure you are aligned on how the API should be designed.
NOTE: The technical solution proposed in an RFC does not require approvalbeyond the normal pull request approval model (e.g. a core team member needsto approve the RFC PR and any subsequent changes to it).
3. Kick-off
Before diving into writing the RFC, it is highly recommended to organize akick-off meeting that includes the API Bar Raiser and any stakeholders thatmight be interested in this RFC or can contribute ideas and direction. The goalof the meeting is to discuss the feature, its scope and general direction forimplementation.
If you are not part of the CDK team at Amazon, reach out to us via #aws-cdk-rfcsand we will help to organize the kick-off meeting.
Our experience shows that such a meeting can save a lot of time and energy.
You can use the tracking issue to record some initial API and design ideas andcollect early feedback and use cases as a preparation for the kick-off meetingand RFC document itself. You can start the meeting by letting participantsobtaining context from the tracking issue.
At the end of the meeting, record any ideas and decisions in the tracking issueand update the checklist to indicate that the kick-off meeting has happened.
4. RFC Document
The next step is to write the first revision of the RFC document itself.
Create a file under text/NNNN-name.md based off of the template under0000-template.md (where NNNN is your tracking issuenumber). Follow the template. It includes useful guidance and tips on how towrite a good RFC.
What should be included in an RFC? The purpose of an RFC is to reduceambiguity and risk and get approval for public-facing interfaces (APIs), whichare "one-way doors" after the feature is released. Another way to think about itis that the goal and contents of the document should allow us to create ahigh-confidence implementation plan for a feature or a change.
In many cases, it is useful to develop a prototype or even start coding theactual implementation while you are writing the RFC document. Take into accountthat you may need to throw your code away or refactor it substantially, but ourexperience shows that good RFCs are the ones who dive into the details. Aprototype is great way to make sure your design "holds water".
5. Feedback
Once you have an initial version of your RFC document (it is completely fine tosubmit an unfinished RFC to get initial feedback), submit it as a pull requestagainst this repo and start collecting feedback.
Contact the CDK core team at #aws-cdk-rfcs (or via email/Slack if you are partof the core team) and reach out to the public and Amazon internal communitiesvia various Slack channels in cdk.dev, Twitter and any otherrelevant forum.
This is the likely going to be the longest part of your RFC process, and wheremost of the feedback is collected. Some RFCs resolve quickly and some can takemonths (!!). Take into account at least 1-2 weeks to allow community andstakeholders to provide their feedback.
A few tips:
- If you decide to resolve a comment without addressing it, take the time toexplain.
- Try to understand where people are coming from. If a comment seems off, askfolks to elaborate and describe their use case or provide concrete examples.
- Work with your API bar raiser: if there are disagreements, @mention them in acomment and ask them to provide their opinion.
- Be patient: it sometimes takes time for an RFC to converge. Our experienceshows that some ideas need to "bake" and solutions oftentimes emerge via ahealthy debate. We've had RFCs that took months to resolve.
- Not everything must be resolved in the first revision. It is okay to leavesome things to resolve later. Make sure to capture them clearly and have anagreement about that. We oftentimes update an RFC doc a few times during theimplementation.
6. API Sign-off
Before you can merge your RFC, you will need the API Bar Raiser to sign-off onthe public API of your feature. This is will normally be described under theWorking Backwards section of your RFC.
To sign-off, the API bar raiser will add the api-approved label to the RFCpull request.
Once the API was signed-off, update your RFC document and add a [x] therelevant location in the RFC document. For example:
[x] Signed-off by API Bar Raiser @foobar
7. Final Comments Period
At some point, you've reached consensus about most issues that were brought upduring the review period, and you are ready to merge. To allow "last call" onfeedback, the author can announce that the RFC enters "final comments period",which means that within a ~week, if no major concerns are raised, the RFC willbe approved and merged.
Add a comment on the RFC pull request, tracking issue (and possibly slack/emailif relevant) that the RFC entered this stage so that all relevant stakeholderswill be notified.
Once the final comments period is over, seek an approval of one of the core teammembers, and you can merge your PR to the main branch. This will move your RFCto the "approved" state.
8. Implementation
For large changes, we highly recommend creating an implementation plan whichlists all the tasks required. In many cases, large implementation should bebroken down and released via multiple iterations. Devising a concrete plan tobreak down the break can be very helpful.
The implementation plan should be submitted through a PR that adds an addendumto the RFC document and seeks the approval of any relevant stakeholders.
Throughout this process, update the tracking issue:
- Add the alias of the "implementation lead"
- Execution plan submitted (label:
status/planning) - Plan approved and merged (label:
status/implementing) - Implementation complete (label:
status/done)
State Diagram
The following state diagram describes the RFC process:
- Proposed - A tracking issue has been created with a basic outline of theproposal.
- Review - An RFC document has been written with a detailed design and a PR isunder review. At this point the PR will be assigned a shepherd from the coreteam.
- Final Comment Period - The shepherd has approved the RFC PR, and announcesthat the RFC enters a period for final comments before it will be approved (~1wk).At this stage, if major issues are raised, the RFC may return to Review.
- Approved - The RFC PR is approved and merged to
master, and the RFC is nowready to be implemented. - Planning - A PR is created with the Implementation Plan section of the RFC.
- Implementing - Implemetation plan is approved and merged and the RFC is activelybeing implemented.
- Done - Implementation is complete and merged across appropriaterepositories.
- Rejected - During the review period, the RFC may be rejected and then it willbe marked as such.
AWS CDK's RFC process owes its inspiration to the Yarn RFC process, RustRFC process, React RFC process, and Ember RFC process
-
我有一个Powershell Lambda，我希望通过AWS CDK部署它，但在运行时遇到问题。 通过手动发布AWSPowerShellLambda部署Powershell可以： 但是，与CDK一起部署的同一脚本不会记录到CloudWatch日志，即使它具有以下权限： powershell脚本当前仅包含以下行，在CLI上由Publish AWSPowerShellLambda部署时可以工作： 注意
-
AWS Cloud Development Kit (AWS CDK) The AWS Cloud Development Kit (AWS CDK) is an open-source software developmentframework to define cloud infrastructure in code and provision it through AWS CloudFor
-
我正在尝试遵循官方教程:https://docs.aws.amazon.com/cdk/latest/guide/gett_started.html 关于发生了什么或者如何调试这个问题有什么线索吗？ 我使用的是带有以下CLI版本的Mac OS X 10.15.6：
-
我有一个AWS架构，其中我介绍了一个配置数据库，多个Lambdas将依赖于此。 配置数据库通过CDK填充：通过创建S3 bucket，将数据上传到S3 bucket，S3 bucket反过来通知将填充数据库的Lambda。 我有其他Lambda依赖于正在填充的数据库，其中一个Lambda位于cron上，最初由CDK通过自定义资源调用，因此计时非常关键。 目前，所有AWS资源都是通过单个堆栈部署的，
-
我是AWS世界的新手。我正在做一个项目，建立一个服务器少的应用程序，作为其中的一部分，我已经创建了4 lambda，工作正常。 接下来，我尝试使用CDK创建一个部署管线；下面是我想做的。 > 从同一个图像创建4个不同的lambda，只需覆盖docker图像中的CMD，并提及lambda处理程序 我在本地安装了CDK，并能够创建堆栈，一切正常。 下面是我的代码片段 --创建docker映像 --从d
-
我浏览了https://docs.aws.amazon.com/cdk/api/latest/python/aws_cdk.aws_elasticache.html。 如何使用AWS-CDK创建Elasticache Redis模板。如果您共享示例代码会更有帮助。