Conversation
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 4m 39s ⏱️ - 1h 49m 34s Results for commit 83a28e4. ± Comparison against base commit 056da83. This pull request removes 4386 tests.♻️ This comment has been updated with latest results. |
Test Results (amd64) - Integration, Bootstrap 5 files ± 0 5 suites ±0 17m 4s ⏱️ - 2h 16m 5s Results for commit 83a28e4. ± Comparison against base commit 056da83. This pull request removes 4768 tests.♻️ This comment has been updated with latest results. |
bentsku
left a comment
There was a problem hiding this comment.
LGTM! Interesting changes, we see the history of things and why they were made that way 😄 just put a comment about the data model of KMS, but this is out of scope of this PR! Nice work 💯
| is_key_rotation_enabled: bool | ||
| rotation_period_in_days: int | ||
| next_rotation_date: datetime.datetime | ||
| previous_keys = [str] |
| grant: KmsGrant | None = None | ||
| if grant_name: | ||
| for existing_grant in store.grants.values(): | ||
| if existing_grant.metadata.get("Name") != grant_name: | ||
| continue | ||
| if existing_grant.metadata.get("KeyId") == key_id: | ||
| grant = existing_grant | ||
| break | ||
|
|
||
| if grant is None: |
There was a problem hiding this comment.
interesting, I mean the change is okay, but ultimately I believe the grants should be part of the KMS Key metadata (a Grant seems to be always linked to a Key), so if it was stored there we wouldn't need to do all of this.
Maybe we could leave a TODO to change the data model such that the KmsKey would hold the grants?
At least from a quick look that's how it feels, that the Grant should be nested inside the Key itself.
Only exception when a Grant operation is spanning multiple keys is list_retirable_grants but I think that'd be fine. Anyway, I was just thinking why we got into this situation in the first place 😄
\cc @k-a-il
There was a problem hiding this comment.
Make sense. I added a todo. I implemented it this way since I believe the change should not break pickle persistence (as the data is already replicated across the two fields). Is my assumption correct? The refactoring you mentioned might be a good use case to test migrations :D
There was a problem hiding this comment.
I implemented it this way since I believe the change should not break pickle persistence (as the data is already replicated across the two fields). Is my assumption correct?
Yes, yes, totally! This is the correct change right now, it just made me think about why it was necessary in the first place 😄 and definitely for the migration, it would be a pretty good test case!
Motivation
This PR improves typing annotations for the KSM store. This is an ongoing effort needed for the new persistence serialization, heavily based on type annotations.
Changes
dict);grant_namesfield from the store. This field was problematic as it was using a tuple as a dictionary key. I noticed that the data contained in this field is actually redundant (grantscontains the same information), and it was used for O(1) lookup on grant names in theCreateGrantoperation. With the current changes, the lookup is O(n).Tests
Related