fix(infra): ensure we set az for primary in postgresql

[arealmaas]

Description

We had an issue where we added HA for prod, but the bicep deployment didn't go through because we need to set the primary az. Setting the primary az to the one that it was added to when created.

Related Issue(s)

• Etablere databasebackup og HA #164

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)

Documentation

• Documentation is updated (either in docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)

[coderabbitai]

📝 Walkthrough

Walkthrough

This update adds an availabilityZone parameter to the PostgreSQL configuration across several Bicep files. In the main infrastructure template, the parameter is added to the postgresConfiguration object and passed into the PostgreSQL module. Additionally, the environment-specific parameter files (for prod, staging, test, and yt01) now include an availabilityZone property with preset values. The existing enableHighAvailability parameter has been replaced with a new highAvailability object that includes more detailed configurations. These changes allow for enhanced configuration options for PostgreSQL deployments.

Changes

Files	Change Summary
.azure/infrastructure/main.bicep	Added a new availabilityZone (string) to the postgresConfiguration parameter and replaced enableHighAvailability with highAvailability (optional object). Passed both parameters to the postgresql module.
.azure/infrastructure/{prod, staging, test, yt01}.bicepparam	Updated the postgresConfiguration parameter to include highAvailability with sub-properties and availabilityZone with environment-specific values ('3' for prod, '2' for staging, '1' for test and yt01).
.azure/modules/postgreSql/create.bicep	Introduced a new type HighAvailabilityConfiguration, added a highAvailability parameter, and updated the availabilityZone parameter description. Removed enableHighAvailability.

Suggested reviewers

• oskogstad

---

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 43930ed and 7342992.

📒 Files selected for processing (6)

• .azure/infrastructure/main.bicep (2 hunks)
• .azure/infrastructure/prod.bicepparam (1 hunks)
• .azure/infrastructure/staging.bicepparam (1 hunks)
• .azure/infrastructure/test.bicepparam (1 hunks)
• .azure/infrastructure/yt01.bicepparam (1 hunks)
• .azure/modules/postgreSql/create.bicep (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (4)

• .azure/infrastructure/yt01.bicepparam
• .azure/infrastructure/test.bicepparam
• .azure/infrastructure/staging.bicepparam
• .azure/modules/postgreSql/create.bicep

⏰ Context from checks skipped due to timeout of 90000ms (1)

• GitHub Check: Dry run deploy infrastructure / Deploy to test

🔇 Additional comments (5)

.azure/infrastructure/prod.bicepparam (2)

39-42: Good enhancement to the high availability configuration

You've replaced the previous boolean enableHighAvailability with a more detailed configuration object that explicitly specifies the mode and standby availability zone. This change provides better control over the PostgreSQL HA setup.

---

44-44: Critical fix to ensure correct primary AZ setting

Setting the primary availability zone to '3' explicitly addresses the core issue in this PR - ensuring the primary AZ matches what was used during initial PostgreSQL instance creation. This should resolve the deployment failures mentioned in the PR description.

.azure/infrastructure/main.bicep (3)

59-59: Good import of the new type definition

You've properly imported the HighAvailabilityConfiguration type for structured HA configuration.

---

66-69: Enhanced parameter definition with proper typing

The changes to the postgresConfiguration parameter object are well-structured:

1. Replacing enableHighAvailability: bool with highAvailability: PostgresHighAvailabilityConfig? provides more detailed configuration
2. Making it optional with ? maintains compatibility with environments that may not use HA
3. Adding availabilityZone: string allows explicit control of the primary zone

This supports the goal of ensuring correct AZ configuration for PostgreSQL deployments.

---

221-224:

❓ Verification inconclusive

Correctly passing parameters to the PostgreSQL module

The parameters are properly passed to the PostgreSQL module:

1. Using optional chaining with postgresConfiguration.?highAvailability ensures the code works even if the property is not defined
2. Explicitly passing availabilityZone ensures the primary zone is set correctly

This implementation addresses the core issue described in the PR objectives.

---

🏁 Script executed:

#!/bin/bash
# Verify if PostgreSQL module accepts these parameters
rg -A 5 "param highAvailability|param availabilityZone" -- "../modules/postgreSql/create.bicep"

Length of output: 170

---

Action Required: Verify PostgreSQL Module Path in Bicep Infrastructure
The changes in .azure/infrastructure/main.bicep correctly pass parameters (using optional chaining for highAvailability and explicitly setting availabilityZone). However, our automated check couldn’t locate the PostgreSQL module file at ../modules/postgreSql/create.bicep, which means we cannot confirm from the repository that these parameters are indeed accepted by the module. Please review the actual file location and verify that the module (whether relocated or renamed) defines and accepts the parameters highAvailability, backupRetentionDays, and availabilityZone.

• Confirm that the PostgreSQL module file is correctly referenced (or update the path if it has changed).
• Manually verify that the module’s implementation accepts these parameters as intended.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.azure/infrastructure/main.bicep (1)

60-68: Add availabilityZone property to postgresConfiguration parameter

A new property (availabilityZone: string) has been added inside the postgresConfiguration object. This enables specifying the availability zone for the PostgreSQL deployment directly from the main template. Please make sure that documentation and corresponding parameter files (e.g., for prod, staging, etc.) are updated accordingly.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e6d3f2e and 43930ed.

📒 Files selected for processing (6)

• .azure/infrastructure/main.bicep (2 hunks)
• .azure/infrastructure/prod.bicepparam (1 hunks)
• .azure/infrastructure/staging.bicepparam (1 hunks)
• .azure/infrastructure/test.bicepparam (1 hunks)
• .azure/infrastructure/yt01.bicepparam (1 hunks)
• .azure/modules/postgreSql/create.bicep (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (1)

• GitHub Check: Dry run deploy infrastructure / Deploy to test

🔇 Additional comments (7)

.azure/infrastructure/staging.bicepparam (1)

41-41: Availability zone added for PostgreSQL instance

The addition of availabilityZone: '2' specifies which Azure availability zone to use for the PostgreSQL instance in the staging environment. This aligns with the PR objective to ensure that the primary availability zone is correctly set during deployment.

.azure/infrastructure/prod.bicepparam (1)

41-41: Correct availability zone added for production

Adding availabilityZone: '3' for the production environment ensures the PostgreSQL instance will be deployed in the right zone. This is especially important for the production environment where enableHighAvailability is set to true (line 39), addressing the issue mentioned in the PR objectives where the bicep deployment failed because the primary AZ wasn't set correctly.

.azure/infrastructure/test.bicepparam (1)

41-41: Test environment availability zone set

Adding availabilityZone: '1' for the test environment ensures consistent configuration across environments. This parameter was missing previously and is now properly set.

.azure/infrastructure/yt01.bicepparam (1)

43-43: YT01 environment availability zone configured

The addition of availabilityZone: '1' ensures the PostgreSQL instance will be deployed in the correct availability zone for the YT01 environment. This completes the consistent configuration across all environments.

.azure/infrastructure/main.bicep (1)

221-223: Pass availabilityZone to the PostgreSQL module

The module instantiation for postgresql now passes the new property via
availabilityZone: postgresConfiguration.availabilityZone. This ensures that the module receives the correct configuration for the availability zone. Verify that the module’s usage of this parameter aligns with the updated HA configuration requirements.

.azure/modules/postgreSql/create.bicep (2)

58-60: Introduce the availabilityZone parameter in the PostgreSQL module

A new parameter (availabilityZone: string) is added along with a description explaining that it denotes the availability zone for the PostgreSQL primary server. This is consistent with changes in the main template and supports the required HA configuration.

---

129-129: Integrate availabilityZone into the PostgreSQL resource properties

Within the postgres resource block, the availabilityZone property is now assigned (i.e. availabilityZone: availabilityZone). Please verify that this property is supported by the selected API version (2024-08-01) and that the passed value aligns with the expected format.

Knut