Closed tnielsen2 closed 1 year ago
As part of this PR, I am attempting to update the code to the latest ref spec, but I am having difficulty getting all CI to pass.
When regen generates the spec, it will sometimes generate the class objects out of order within the Python module.
When I fix those errors, the regen portion of the PR fails, but I can get lint to pass.
The main goal of this PR is to update RDS GP3 validator logic, while attempting to update refspec so CI will pass, but I have been unsuccessful. I seem to be able to only get Lint or Refspec to pass.
@markpeek What is the course for action for this PR? How important is it to have both CI and Refspec generation pass? I looked into patch scripts to address this issue, but I couldn't seem to figure it out on own. Any insight is appreciated.
With the latest commit, at this moment, lint is failing due to class objects not being generated in the correct order, as well as what seems to be circular dependencies in the connect
module with the introduction of new AWS Properties and nested properties.
What is the best way for this to be fixed? And if it is a patch script, what operations would I be using to fix these?
I have applied the patch changes to get this to pass lint and refspec generation. I have updated the PR with the necessary ride-along refspec updates.
@tnielsen2 thank you for the PR. Some of the change are needed but there is still an issue with regenerating from the spec. I looked at it this weekend and I think I have a change that should allow this to work better. I'm going to create a branch and start applying the older spec versions into it so we can better reason about the changes. I'll ping back here when I've pushed the new branch out for your review. Thank you for your patience.
I have rebased from main
with upstream changes and this is ready for review after the latest round of discussions/conversation @markpeek
Thanks for all you do!
Thank you for the PR and getting it rebased.
Troposphere has a new validator released in 4.3.1 that does not allow omitting the
Iops
attribute when gp3 and small StorageType parameters are passed.If we passed
Iops
to an instance under 400GB, with EngineType = mysql, postgres, mariadb; deploying CFN will provide the following deployment error:Documentation here outlines the possible combinations of parameters related to GP3, EngineType, and conditional values/requirements.
Reviewing CloudFormation documentation here states that IOPS is only required for
io1
.This PR updates validation logic to allow small storage RDS instances backed by GP3 to be launched with a valid configuration values as per the above linked documentation.
Edit post submittal:
Summary of refspec ride-along changes/fixes:
scripts/gen.py
for wafv2Encryption
Type