-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
CloudFormation: Store resource scaffolding in 'generated' directory. #13534
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
Conversation
0713e38 to
d8931e2
Compare
Test Results - Alternative Providers584 tests - 887 325 ✅ - 564 18m 21s ⏱️ - 14m 54s Results for commit 806a1d5. ± Comparison against base commit 6269d34. This pull request removes 887 tests.♻️ This comment has been updated with latest results. |
Test Results (amd64) - Integration, Bootstrap 5 files ± 0 5 suites ±0 2h 5m 25s ⏱️ - 28m 50s Results for commit 806a1d5. ± Comparison against base commit 6269d34. This pull request removes 1428 tests.♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 33m 5s ⏱️ - 20m 59s Results for commit 806a1d5. ± Comparison against base commit 6269d34. This pull request removes 1045 tests.♻️ This comment has been updated with latest results. |
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 am hugely on board with this change, thank you! I have raised an issue about hiding the docstrings which I think will help developers build a conforming implementation (until we enforce an engine -> resource provider contract at least). I'd like to open a discussion about that.
I tried this out while implementing AWS::RDS::DBProxyEndpoint for a feature request. Thank you for making this change backwards compatible! It means that we can migrate the resource providers gradually! I really appreciate this.
I found that the files needed formatting. Can we maybe run make format-modified (or similar) after rendering the templates? That would make the initial experience much nicer.
| self, | ||
| request: ResourceRequest[{{ resource }}Properties], | ||
| ) -> ProgressEvent[{{ resource }}Properties]: | ||
| """ |
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.
issue: I don't like removing these docstrings to the base model. I realise that their content is autogenerated, and will get out of sync with the generated code but the docstrings are a great reminder of what
- properties the model needs to set (
writeOnlyProperties) - potential operations the method may need to invoke (through required iam actions)
I can see the docstring if I hover the method in PyCharm, but for people who have not written many resource providers it's not intuitive that this docstring is present. I bet the wouldn't look in the generated subdir anyway. To that end, relying on the schema.json file is also not a good solution.
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 was hoping to start a discussion here rather than just implementing my suggestion. I don't 100% think this is a good approach because it introduces an element of the autogenerated values into the manually updated base class. I don't know if you have any better suggestions?
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 fine with this suggestion, which is why I went ahead and implemented it. These files will only be auto-generated once, and then manually edited every other time. Given that service teams will be writing the resource providers, and they're not going to be experts at writing them, having extra clues will be helpful to get them started.
Honestly though, I think a lot of these templates instructions (and templated test cases) could be re-evaluated, given the behaviour of the new CloudFormation engine, but I was going to think about this in a later PR. For example, I'm not yet clear on the whole permissions model. Should these be evaluated/checked by the engine, rather than the providers, which means we don't really need them in the scaffolding comments?
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.
For me they serve as documentation and guidance for the implementor first and foremost. I also agree with your last point in that I don't think the engine should check permissions. I don't think anything should check permissions, it should be apparent from the failed operation that an IAM action is missing (though perhaps we can be helpful with this information when presenting it to the user given we have access to the required permissions).
I think you are right, the best place for these comments is in the manually edited files. If they go stale it's not the end of the world as they are guidance anyway. Thanks for the discussion!
...k-core/localstack/services/cloudformation/scaffolding/templates/provider_base_template.py.j2
Show resolved
Hide resolved
|
Thanks @simonrw , I've made your suggested changes. |
simonrw
left a comment
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.
Thanks for making these changes! This looks like a huge improvement to the way we manage resource providers and scaffold them in the future!
localstack-core/localstack/services/cloudformation/scaffolding/__main__.py
Outdated
Show resolved
Hide resolved
| self, | ||
| request: ResourceRequest[{{ resource }}Properties], | ||
| ) -> ProgressEvent[{{ resource }}Properties]: | ||
| """ |
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.
For me they serve as documentation and guidance for the implementor first and foremost. I also agree with your last point in that I don't think the engine should check permissions. I don't think anything should check permissions, it should be apparent from the failed operation that an IAM action is missing (though perhaps we can be helpful with this information when presenting it to the user given we have access to the required permissions).
I think you are right, the best place for these comments is in the manually edited files. If they go stale it's not the end of the world as they are guidance anyway. Thanks for the discussion!
…o separate auto-generated code from human-written code.
570b146 to
806a1d5
Compare
Motivation
Generate CloudFormation resource scaffolding into a service's
resource_providers/generateddirectory to separate auto-generated code from hand-written code. Resource provider classes should inherit from their auto-generated base class, permitting automatic updates of the base class and associated data types, without overwriting any hand-written code.Changes
generated/<resource>_base.pyfile that contains auto-generated type definitions, as well as abstract CRUD methods. These can be re-generated at any time, without overwriting hand-written code.*_plugin.pyand*.schema.jsonfiles into thegeneratedsubdirectory.<resource>.pyfile that inherits types/methods from<resource>_base.py. This file is expected to be modified by hand and contain the full provider implementation.AWS::SQS::QueuePolicyprovider to demonstrate that this new split works correctly (other resource providers forAWS::SQSwill be updated in a later PR).Tests
Tested by:
AWS::SQS::QueuePolicyto use this new structure (included in this PR)Related