-
Notifications
You must be signed in to change notification settings - Fork 65
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
Add MySQLServerConfiguration managed resource #299
Conversation
The behavior I mentioned above (valid configurations are determined on the server side and new ones cannot be created) is the same for PostgreSql. In description of PostgreSQLServerConfiguration PR (#285), there is the following expression:
My observation for both MySql and PostgreSql does not agree with this observation. As I mentioned above, all valid configurations are defined on the server side and the Get call returns successfully for a valid configuration whether it is manipulated or not. So, if there is no error in the old observation, there may have been a behavior change in the Azure Sdk since then. It should also be noted that there is no problem in the main workflow on the PostgreSql side. That is, there is no error in configuring a valid parameter (by creating a Managed Resource) or reverting the configured parameter (by deleting the Managed Resource). The improvement mentioned here is that when trying to configure an invalid parameter, the error encountered is reported in status.conditions (We do not see any errors now). The improvement on the PostgreSql side is not included to this PR, as it is not the subject of this PR, and because the PostgreSql resources that were created in the past may be running with the old behavior. Thanks to @ulucinar for his guidance on this task. |
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.
Hi @sergenyalcin,
Thank you for working on this. I think there are no blockers for merging this PR, and I've left some comments for you to consider. Could you please also manually test the import case, i.e., no config value is specified in the MR to have it late-initialized? Could you please also check if we can increase coverage with some reasonable test cases?
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.
Thank you very much @sergenyalcin!
Because we do not squash commits and preserve commit history, we should author a clean & descriptive commit history. @sergenyalcin could you please squash your commits? |
Signed-off-by: sergenyalcin <yalcinsergen97@gmail.com>
3adacfd
to
f5044ee
Compare
Signed-off-by: sergenyalcin yalcinsergen97@gmail.com
Description of your changes
Fixes #286
Implementing MySQLServerConfiguration managed resource.
Support for configuring MySQLServer parameters. If the configuration has been applied successfully, the MySQLServerConfiguration MR will have the Ready condition in its status.
I would like to say a few things about the problem I encountered while working on this.
Valid configurations of the MySQL Server have been determined in server side and new ones cannot be created. Only existing valid configurations can be updated. Therefore, if the config cannot be found in the result of the get call (in Observe function), instead of returning nil, an error is returned and the error is reported in status conditions of the MySQLServerConfiguration managed resource.
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested