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

AVM-Review #9

Open
1 task done
mbilalamjad opened this issue Mar 21, 2024 · 2 comments
Open
1 task done

AVM-Review #9

mbilalamjad opened this issue Mar 21, 2024 · 2 comments

Comments

@mbilalamjad
Copy link
Contributor

mbilalamjad commented Mar 21, 2024

Dear module owner,

As per the agreed module ownership requirements & responsibilities at the time of assignment, the AVM Team is opening this issue to request you to kindly review your module against the below AVM specs and confirm that they are met by the module. We appreciate if you don't close this issue till the review is complete. This review is required as a pre-req to be able to eventually publish the module as v1. AVM team would be happy to assist with the review and any questions that you might have around this.

Requested action is to complete below tasks and update the status column in the table below.

Tasks

Preview Give feedback
# Spec Status [Y/N/NA] Comments
1 ID: SFR1 - Category: Composition - Preview Services Y
2 ID: SFR2 - Category: Composition - WAF Aligned #9 (comment)
3 ID: SFR3 - Category: Telemetry - Deployment/Usage Telemetry Y
4 ID: SFR4 - Category: Telemetry - Telemetry Enablement Flexibility Y
5 ID: SFR5 - Category: Composition - Availability Zones #9 (comment)
6 ID: SFR6 - Category: Composition - Data Redundancy NA
7 ID: SNFR25 - Category: Composition - Resource Naming Y
8 ID: SNFR1 - Category: Testing - Prescribed Tests Y
9 ID: SNFR2 - Category: Testing - E2E Testing Y
10 ID: SNFR3 - Category: Testing - AVM Compliance Tests Y
11 ID: SNFR4 - Category: Testing - Unit Tests Y
12 ID: SNFR5 - Category: Testing - Upgrade Tests NA Waiting initial release first
13 ID: SNFR6 - Category: Testing - Static Analysis/Linting Tests Y
14 ID: SNFR7 - Category: Testing - Idempotency Tests Y Done manually. Should be handled by the CD pipeline.
15 ID: SNFR24 - Category: Testing - Testing Child, Extension & Interface Resources Y
16 ID: SNFR8 - Category: Contribution/Support - Module Owner(s) GitHub Y
17 ID: SNFR20 - Category: Contribution/Support - GitHub Teams Only Y
18 ID: SNFR9 - Category: Contribution/Support - AVM & PG Teams GitHub Repo Permissions Y
19 ID: SNFR10 - Category: Contribution/Support - MIT Licensing Y
20 ID: SNFR11 - Category: Contribution/Support - Issues Response Times Y
21 ID: SNFR12 - Category: Contribution/Support - Versions Supported Y
22 ID: SNFR23 - Category: Contribution/Support - GitHub Repo Labels Y
23 ID: SNFR14 - Category: Inputs - Data Types Y
24 ID: SNFR22 - Category: Inputs - Parameters/Variables for Resource IDs Y
25 ID: SNFR15 - Category: Documentation - Automatic Documentation Generation Y
26 ID: SNFR16 - Category: Documentation - Examples/E2E Y
27 ID: SNFR17 - Category: Release - Semantic Versioning Y
28 ID: SNFR18 - Category: Release - Breaking Changes Y
29 ID: SNFR19 - Category: Publishing - Registries Targeted Y
30 ID: SNFR21 - Category: Publishing - Cross Language Collaboration Y
31 ID: RMFR1 - Category: Composition - Single Resource Only Y
32 ID: RMFR2 - Category: Composition - No Resource Wrapper Modules Y
33 ID: RMFR3 - Category: Composition - Resource Groups Y
34 ID: RMFR4 - Category: Composition - AVM Consistent Feature & Extension Resources Value Add Y
35 ID: RMFR5 - Category: Composition - AVM Consistent Feature & Extension Resources Value Add Interfaces/Schemas Y
36 ID: RMFR8 - Category: Composition - Dependency on child and other resources Y
37 ID: RMFR6 - Category: Inputs - Parameter/Variable Naming Y
38 ID: RMFR7 - Category: Outputs - Minimum Required Outputs Y
39 ID: RMNFR1 - Category: Naming - Module Naming Y
40 ID: RMNFR2 - Category: Inputs - Parameter/Variable Naming Y
41 ID: RMNFR3 - Category: Composition - RP Collaboration Y
42 ID: PMFR1 - Category: Composition - Resource Group Creation NA
43 ID: PMNFR1 - Category: Naming - Module Naming NA
44 ID: PMNFR2 - Category: Composition - Use Resource Modules to Build a Pattern Module NA
45 ID: PMNFR3 - Category: Composition - Use other Pattern Modules to Build a Pattern Module NA
46 ID: PMNFR4 - Category: Hygiene - Missing Resource Module(s) NA
47 ID: PMNFR5 - Category: Inputs - Parameter/Variable Naming NA
48 ID: TFFR1 - Category: Composition - Cross-Referencing Modules Y
49 ID: TFFR2 - Category: Outputs - Additional Terraform Outputs Y
50 ID: TFNFR1 - Category: Documentation - Descriptions
51 ID: TFNFR2 - Category: Documentation - Module Documentation Generation Y
52 ID: TFNFR3 - Category: Contribution/Support - GitHub Repo Branch Protection Y
53 ID: TFNFR4 - Category: Composition - Code Styling - lower snake_casing Y
54 ID: TFNFR5 - Category: Testing - Test Tooling Y
55 ID: TFNFR6 - Category: Code Style - The Order of resource and data in the Same File Y
56 ID: TFNFR7 - Category: Code Style - The Use of count and for_each Y
57 ID: TFNFR8 - Category: Code Style - Orders Within resource and data Blocks Y Order should be handled by tflint. Too complex to check manually
58 ID: TFNFR9 - Category: Code Style - Order within a module block Y Order should be handled by tflint. Too complex to check manually
59 ID: TFNFR10 - Category: Code Style - Values in ignore_changes passed to provider, depends_on, lifecycle blocks are not allowed to use double quotations Y Not sure about that rule as it is a hcl rule that will be detected by any terraform command (fmt, validate or plan
60 ID: TFNFR11 - Category: Code Style - null comparison as creation toogle Y
61 ID: TFNFR12 - Category: Code Style - Optional nested object argument should use dynamic Y
62 ID: TFNFR13 - Category: Code Style - Use coalesce or try when setting default values for nullable expressions Y Love to discuss more about Good and Bad examples
63 ID: TFFR14 - Category: Inputs - No enabled or module_depends_on variable Y
64 ID: TFNFR15 - Category: Code Style - Order to define variable Y
65 ID: TFNFR16 - Category: Code Style - Name of a variable MUST follow rules Y
66 ID: TFNFR17 - Category: Code Style - Every variable MUST come with a description Y
67 ID: TFNFR18 - Category: Code Style - Every variable MUST have an appropriate type Y
68 ID: TFNFR19 - Category: Code Style - variable containing confidential data should be declared as sensitive = true Y
69 ID: TFNFR20 - Category: Code Style - Declare nullable = false when it’s possible Y
70 ID: TFNFR21 - Category: Code Style - MUST NOT declare nullable = true Y
71 ID: TFNFR22 - Category: Code Style - MUST NOT declare sensitive = false Y
72 ID: TFNFR23 - Category: Code Style - variable with sensitive = true MUST NOT have default value unless the default value represents turning off a feature, like default = null or default = [] Y
73 ID: TFNFR24 - Category: Code Style - Deal with deprecated variable Y
74 ID: TFNFR25 - Category: Code Style - All verified modules MUST have terraform.tf file and required_version MUST be set Y
75 ID: TFNFR26 - Category: Code Style - Providers MUST be declared in the required_providers block in terraform.tf and MUST have a constraint on minimum and maximum major version Y
76 ID: TFNFR27 - Category: Code Style - Declaration of a provider in the module Y
77 ID: TFNFR28 - Category: Code Style - output MUST be arranged alphabetically Y
78 ID: TFNFR29 - Category: Code Style - output contains confidential data should declare sensitive = true Y
79 ID: TFNFR30 - Category: Code Style - Dealing with Deprecated outputs Y
80 ID: TFNFR31 - Category: Code Style - locals.tf MUST contain only locals blocks Y
81 ID: TFNFR32 - Category: Code Style - local should be arranged alphabetically Y
82 ID: TFNFR33 - Category: Code Style - local should use types as precise as possible Y
83 ID: TFNFR34 - Category: Code Style - Feature toggle MUST be used to ensure forward compatibility of versions and avoid unexpected changes caused by upgrades Y
84 ID: TFNFR35 - Category: Code Style - Changes that might be breaking change MUST be reviewed with caution Y
85 ID: TFNFR36 - Category: Code Style - Example code MUST set prevent_deletion_if_contains_resources to false in provider block Y
86 ID: TFNFR37 - Category: Code Style - Module owner MAY use tools like newres Y
@LaurentLesle
Copy link
Collaborator

@mbilalamjad Questions related to SFR5
Are we saying I should change the default value from

variable "zones" {
  type        = set(string)
  default     = null
  description = "(Optional) Specifies a list of Availability Zones in which this Kusto Cluster should be located. Changing this forces a new Kusto Cluster to be created."

  validation {
    condition     = var.zones == null ? true : setunion(["1", "2", "3"], var.zones) == toset(["1", "2", "3"])
    error_message = "Zones can be null or a combination of '1', '2' or '3'"
  }
}

to

variable "zones" {
  type        = set(string)
  default     = ["1", "2", "3"]
  description = "(Optional) Specifies a list of Availability Zones in which this Kusto Cluster should be located. Changing this forces a new Kusto Cluster to be created."

  validation {
    condition     = var.zones == null ? true : setunion(["1", "2", "3"], var.zones) == toset(["1", "2", "3"])
    error_message = "Zones can be null or a combination of '1', '2' or '3'"
  }
}

@LaurentLesle
Copy link
Collaborator

SFR2 mentions "Alignment SHOULD prioritize best-practices and security over cost optimization,"

Therefore I presume I should enable double encryption by default?

variable "double_encryption_enabled" {
  type        = bool
  default     = null
  description = "(Optional) Is the cluster's double encryption enabled? Changing this forces a new resource to be created."
}

Also enable CMK by default?

variable "customer_managed_key" {
  type = object({
    key_vault_resource_id              = optional(string)
    key_name                           = optional(string)
    key_version                        = optional(string, null)
    user_assigned_identity_resource_id = optional(string, null)
  })
  default     = {}
  description = "Customer managed keys that should be associated with the resource."
}

and soft delete should be enabled by default to a value? Default in the provider is unlimited.

variable "soft_delete_period" {
  type        = string
  description = "(Optional) The time the data should be kept before it stops being accessible to queries as ISO 8601 timespan. Default is unlimited. For more information see: ISO 8601 Timespan."
  default     = null
}

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

No branches or pull requests

2 participants