Posted on Leave a comment

Deploy azurerm function app with zip_deploy_file terraform

When you need to deploy code in a function app using terraform you can use the zip_deploy_file parameter. Using this you can specify a zip file that will be created from your committed code and by doing so you can dynamically deploy code using terraform.

The first thing that you will need to do is to create a folder with the code that you want to commit in the function_app. In my example I have the terraform files inside the aws and azure folders and in the same directory I have a folder called resources where the code is located. This code need to be deployed in the serverless function app.

Create a data archive_file with terraform and specify where your code is located. You should correctly point where the files are stored.

data "archive_file" "python_function_package" {  
  type = "zip"  
  source_file = "../resources/" 
  output_path = ""

Then you should use the above data archive and use it along with zip_deploy_file.

resource "azurerm_linux_function_app" "functionapp" {
  name                = var.serviceplan_name
  resource_group_name =
  location            = azurerm_resource_group.rg.location

  storage_account_name       =
  storage_account_access_key =
  service_plan_id            =
  zip_deploy_file = data.archive_file.python_function_package.output_path
  app_settings              = "${var.app_settings}"

  site_config {
    application_stack {
        python_version = "3.10"


When you deploy your terraform code the function app will correctly upload the code in your infra component and you can check that by navigating inside the code on azure portal.

azurerm_linux_function_app | Resources | hashicorp/azurerm | Terraform | Terraform Registry

Posted on Leave a comment

Download repos with ssh keys on Gitlab with MFA enabled

When you enable MFA in Gitlab you may face issues when interacting with git repositories. Some of your commands like git pull, push etc could fail and this is done because of the MFA.

There is a way to resolve those issues by communicating with ssh keys. The procedure to create and upload your keys are described in the below article.

However sometimes this may not work as in my case. The issue was that the ssh key for some reason could not be found correctly from the computer.

In order to bypass I used the ssh-add command and then pointed the directory of the key.

ssh-add ~/.ssh/gitlab_id_rsa

After this action your gitlab interaction will start working.

Posted on 2 Comments

error: the namespace from the provided object does not match the namespace. You must pass –namespace to perform this operation

When you need to copy a secret from one namespace to another in a Kubernetes cluster you may face the below error.

error: the namespace from the provided object "" does not match the namespace "". You must pass --namespace to perform this operation

The issue can be found because of the origin namespace that is referenced inside the secret. In order to bypass you can export the secret and change the referenced namespace.

kubectl get secret mysecret --namespace=ns1 -o yaml > export.yaml

In order to get it work you will need to change the namespace according to your new namespace in the export.yaml and apply it.

namespace: ns2
Posted on Leave a comment

Failed to start up WiredTiger under any compatibility version. This may be due to an unsupported upgrade or downgrade

When you upgrade a standalone mongodb instance you can end up having the issue described below. When you have a version oldest than 4.4 in mongodb you should first upgrade to version 4.2 and then to version 4.4. During those steps however you must not forget to change the featureCompatibilityVersion. If you do not change this property mongodb will stop working.

"ctx":"initandlisten","msg":"Failed to start up WiredTiger under any compatibility version. This may be due to an unsupported upgrade or downgrade."}

Upgrade a Standalone to 4.4 — MongoDB Manual

You can get your current compatibility Version by using the mongo shell.

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

In this end you should change your compatibility to 4.2 before upgrading to 4.4 in order for the upgrade to be performed successfully.

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )