Skip to content
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

Refactor customization opt out flag #569

Merged
merged 12 commits into from
Feb 10, 2025
Merged

Conversation

nelsonkopliku
Copy link
Member

@nelsonkopliku nelsonkopliku commented Feb 10, 2025

Description

This PR changes the customizable: true|false flag in check's spec to disable_customization: true.

Note that in the catalog disable_customization is being returned as specified in the check (or its default value), while in the group specific api it plays a role in determining whether something is customizable or not.

@nelsonkopliku nelsonkopliku marked this pull request as ready for review February 10, 2025 15:10
@nelsonkopliku nelsonkopliku force-pushed the refactor-cutomizable-flag branch from 2ce6fa5 to 9d36c87 Compare February 10, 2025 15:14
@nelsonkopliku nelsonkopliku force-pushed the refactor-cutomizable-flag branch from 9d36c87 to c6e356e Compare February 10, 2025 15:22
Copy link
Contributor

@arbulu89 arbulu89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @nelsonkopliku
2 things:

  • I know I will be annoying with this but, wouldn't be better to use customization_disabled instead of disable_customization. We are being declarative until now in the dsl and disable_customization looks imperative. I don't know, it looks out of place. Even when we consume the catalog endpoint to get a disable_customization entry looks strange. @stefanotorresi proposed this value anyway...
  • Does the root entry have precedence over the individual ones? I mean, putting the root value to true makes all the specific values ignored?

Copy link
Member

@EMaksy EMaksy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code is great, just found a typo and a comment about the table formatting.

| `env.architecture_type` | one of `classic`, `angi` | [Architecture types](https://github.com/trento-project/web/blob/main/lib/trento/clusters/enums/hana_architecture_type.ex) | `cluster_type` is one of `hana_scale_up`, `hana_scale_out`
| `env.ensa_version` | one of `ensa1`, `ensa2`, `mixed_versions` | [ENSA version](https://github.com/trento-project/web/blob/main/lib/trento/clusters/enums/cluster_ensa_version.ex) | `cluster_type` is `ascs_ers`
| `env.filesystem_type` | one of `resource_managed`, `simple_mount`, `mixed_fs_types` | [Filesystem type](https://github.com/trento-project/web/blob/main/lib/trento/clusters/enums/filesystem_type.ex) | `cluster_type` is `ascs_ers`
| name | Type | Reference | Applicable |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the formatting is a bit harder not tbh...

@nelsonkopliku
Copy link
Member Author

Hey @arbulu89

  • I know I will be annoying with this but, wouldn't be better to use customization_disabled instead of disable_customization. We are being declarative until now in the dsl and disable_customization looks imperative. I don't know, it looks out of place. Even when we consume the catalog endpoint to get a disable_customization entry looks strange. @stefanotorresi proposed this value anyway...

Not a problem for me, gonna change.

  • Does the root entry have precedence over the individual ones? I mean, putting the root value to true makes all the specific values ignored?

In the catalog you will get what the specification is in the check, so no interdependencies.
In the group specific api if a check is specified with customization_disabled: false, has impact on the customizable fields of a SelectableCheck and on its values.

@nelsonkopliku
Copy link
Member Author

@arbulu89 @EMaksy I believe I addressed all the feedback, thanks!

@nelsonkopliku nelsonkopliku changed the title Refactor cutomizable flag Refactor customization opt out flag Feb 10, 2025
Copy link
Contributor

@arbulu89 arbulu89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@nelsonkopliku nelsonkopliku merged commit 7674388 into main Feb 10, 2025
12 of 13 checks passed
@nelsonkopliku nelsonkopliku deleted the refactor-cutomizable-flag branch February 10, 2025 16:55
@coveralls
Copy link
Collaborator

coveralls commented Feb 13, 2025

Coverage Status

coverage: 96.866% (+0.1%) from 96.741%
when pulling 98eae53 on refactor-cutomizable-flag
into 87cee98 on main.

@coveralls
Copy link
Collaborator

Coverage Status

coverage: 96.898% (+0.2%) from 96.741%
when pulling 9267f9b on refactor-cutomizable-flag
into 87cee98 on main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants