magodo

Discussion below based on terraform-provider-azurerm v4.13.0

Problem

#27733 Introduces a couple of breaking changes:

1. Introduces storage_account_id in azurerm_storage_container and azurerm_storage_share and deprecates the storage_account_name.
2. Depending on whether the new storage_account_id or the the deprecated storage_account_name is used, the two resources above will change their behavior:

• storage_account_name used: Data plane API is used to manage the resource. The resource id is the data plane endpoint

magodo

use std::cmp::max;
use std::collections::{HashMap, HashSet};
use std::env;
use std::fs::read_to_string;

#[derive(Debug, Clone, Copy, Hash, PartialEq, Eq)]
struct Point {
    x: usize,
    y: usize,
}

magodo

Storage data plane access TSG

1. Create azurerm_storage_account: accounts.Client#GetServiceProperties: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

Reason

1. The private endpoint is not correctly setup. The reference config can be found at https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/private_endpoint

   Fix: Setup the PE correctly

magodo

#!/bin/bash

# This script setup aztfy and run it in batch mode for terrafying a resource group.
# Afterwards, it will download the output files (incl. HCL and state file) to your local fs.

set -e

MYDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
MYNAME="$(basename "${BASH_SOURCE[0]}")"

magodo

type Foo struct {
	A string `json:"a"`
}

func (foo *Foo) UnmarshalJSON(data []byte) error {
//TODO
}

magodo

This gist is to demonstrate how to reproduce Azure policy related issues when creating definitions within or assigning into a newly created management group.

This can be used to reproduce issue: hashicorp/terraform-provider-azurerm#12478.

The configuration is split to two parts, which should be copied to two TF workspaces and run in sequence.

• The first one (main1.tf) is to provision a parent mgmt group and create a custom policy definition within it
• The second one (main2.tf) is to provision a child mgmt group and then assign the inherited policy definition to it

There is one thing worth mentioning in the main2.tf, the custom policy definition is retrieved from a data source, where you can either get it from the parent mgmt group or the child. Actually, each one ends up with the same definition (i.e. the same resource id).

magodo

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "test" {
  name = "fwpolicy-test"
  location = "westeurope"
}

resource "azurerm_public_ip" "test" {

magodo

provider "azurerm" {
  features {}
}
resource "azurerm_resource_group" "test" {
  name     = "acctestRG-220121144644318289"
  location = "West Europe"
}
resource "azurerm_storage_account" "test" {
  name                     = "accsa220121144644318289"
  resource_group_name      = azurerm_resource_group.test.name

magodo

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

magodo

package main

import "fmt"

func hello(name string) {
        if name == "" {
                fmt.Print("name?")
                name = readString()
        }