mitzen

 Maintaining a repository of terraform modules can be challenging at times and we cannot expect all our team to migrate over to azurerm 4.2 for example.  In order to ensure that our test would continue to work (terraform test will use the latest version of the azurerm by default), we can use the following approach to lock down azurerm providers for your tests. This is applicable to other providers too. We have the following folder setup. There's a setup folder under tests folders. Then in the terraform test file called default.tftest.hcl, we have the following code to references our provider.  Referencing our azurerm providers 3.0 from test file.  # setup specific test run "setup_tests" {   module {     source = "./tests/setup"   } } And finally in our /test/setup/main.tf we have the following contents terraform {   required_providers {     azurerm = {       source   = "hashicorp/azurerm"       version = "~> 3.0"     }   } }

  While trying to get my python code to run on a build agent, i bump into this error "TypeError: 'type' object is not subscriptable Python". It turns out that my code was using python 3.8 and I had to do some import from typings with the code below from typing import Dict. List Then I had to update my code to use Dict instead of dict. 

 Bump into this error while trying to test our network connectivity using network watcher. I disabled my VM nsg on the network card level - this technically should allowed all incoming/outgoing traffic - this means no restrictions. This can be really confusing. 

  You can mock your tests by using  - mock providers - in this scenario you do not call the providers and do not require credentials to be configured. This is the fastest because it doesn't make a actual call to the providers.  - override block - mocking out certain resources, data and modules. This allow us to specifically mock out certain or all resources/data or module. An example can be shown here. As your can see here, we mock out azurerm. If you run terraform init and terraform test, you will noticed test run much faster. mock_provider "azurerm" {} run " resource - group-name-created-correctly" {     variables {     prefix = "test"   }       command = plan   assert {     condition     = azurerm_resource_group.example.name == "myrg"     error_message = "Resource group created is not expected"   } } run "storage-account-prefix-created-correctly" {   variable s {     prefix = "dev"   }     command

To test terraform module, you can place your module into folder, let's call module. In your test that you place in the root directory, you can have the following: run " resource - group-name-created-correctly" {     variables {     prefix = "test"   }  module {     source = "./modules"   }       command = plan   assert {     condition     = output.resource_group_name == "myrg"     error_message = "Resource group created is not expected"   } } Then run terraform init and terraform test to execute your tests. As shown in the diagram above, you need to declare output from your module - and in this case we have our output called resource_group_name. All we need to do is, use the output keyword and append whatever variable we have just output.  The output full code. # Outputs output "storage_account_name" {   description = "The name of the storage account"   value       = azurerm_storage_account.example.name }

  I have been trying to get started with terraform test and here is an example of a very simple test.  It just test for resource group and storage account name on the plan stage.  Essentially test file has to end with tftest.hcl extension. Here is an example to create resource group and storage account. # Terraform Configuration with Provider Version terraform {   required_providers {     azurerm = {       source  = "hashicorp/azurerm"       version = "~> 4.2 " # Specifies the version of the AzureRM provider (e.g., any 3.x version)     }   }   #backend "azurerm" {   # resource_group_name  = "terraform-backend-rg"   # storage_account_name = "terraformbackendsa" # Must be globally unique   # container_name       = "tfstate"   # key                  = "terraform.tfstate"   #}   #required_version = ">= 1.3.0" # Specifies the minimum Terraform version } # Required Providers provider "azurerm"

 This can be handy when we want to setup and install kind curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin/ kind create cluster

  You can find lots of cilium material from here:-  https://isovalent.com/resource-library/labs/?utm_source=website-cilium&utm_medium=referral&utm_campaign=cilium-lab

 We can configure aspnet core app url in launchSettings.json and appsettings.json. A couple of test would reveal that lanchSettings.json is being evaluated then appsettings.  If you would like to override launch settings.json simply the following into appsettings.json.   "Kestrel" : {     "EndPoints" : {       "Http" : {         "Url" : "http://0.0.0.0:5090"       }     }   }

In this setup, we will be setting up centralize hotchoc grapql federation that resolves schema residing in another services. The gateway does not import or contains subgraph schema. It does not require developer to copy schema from subgraph over.   In a centralize approach, gateway reference subgraph schemas. Stitching generally happens when we would like to extend our subgraphs for example, introducing another query name. We will see more of this. Inline with the federation intention,  if a request for product info, the product subgraph would return product info while leaving reviews to be resolved by another subgraph service.  We will be creating 5 projects  - the gateway - this main graphql allows us to query other subgraph define below. - product subgraph - a simple subgraph that shows product info - review subgraph - a slightly more complicated subgraph that provides review information - account subgraph  - inventory subgraph  Github repository  https://github.com/mitzenjeremywoo/

 This is a good link that might help with understanding istioctl proxy outputs. https://www.envoyproxy.io/ docs/envoy/latest/intro/arch_ overview/operations/dynamic_ configuration

Bump into this weird hotchoc error while trying to run 'dotnet run -- schema export --output schema.graphql' to generate my schema.  This is what my hotchoc types looks like. It turn out that I have a static method which prevented the auto code generations to work properly.  using System . Collections . Generic ; using HotChocolate ; using HotChocolate . Types ; using HotChocolate . Types . Relay ; namespace Reviews . Types {     [ QueryType ]     public class Query     {               [ NodeResolver ]         public static Review GetReview (         [ Service ] ReviewRepository repository ,         int upc ) =>         repository . GetReview ( upc );           } } To resolve this, simply remove the static method in my Query.