How should revision management work in preview? about azure-container-apps HOT 12 CLOSED

@villeah thanks for providing more details, that's super useful. I found a bug on our end where a revision fails to create if you first create an application that specifies a revision suffix ("revisionSuffix": "services-revision"), and then later you update the application without providing a revision suffix. The expected behavior here is that a new revision will be created with a random suffix (which is the default behavior when you don't specify a suffix).

While I work on fixing this, a temporary work around is to always provide a revision suffix when updating the application, or simply omit revision suffixes entirely, until this bug is fixed.

Thanks again for reporting this. I'll leave this issue open until a fix is rolled out.

from azure-container-apps.

Yes, sorry for the delay on this. We have a fix in for it and will roll out soon.

from azure-container-apps.

@sshquack Because there were no changes, no revision was created. It's not required that new revisions must have a new image tag, something else (e.g., environment variables) changing will create a new revision too. You can also cause your existing revision's replicas to pick up the updated image by calling az containerapp revision restart.

However, it's not typically a good practice to reuse tags. As different replicas can pull the image at different times, your revision can end up with different replicas running different versions of your app that have the same tag. See this doc for guidance: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-image-tag-version

from azure-container-apps.

@vturecek What's the status on this one please ? 5 months ago, you said the fix was rolling out. ACA is GA but the issue is still open. thanks

from azure-container-apps.

This issue is solved with CLI adding PATCH support

from azure-container-apps.

Thanks @villeah. We are investigating it.

from azure-container-apps.

@villeah did the az containerapp update command succeed? And just to be sure, you provided a different image or tag when you did az containerapp update --image than the one you used when you first created the Container App?

from azure-container-apps.

@vturecek Yes it finished without any errors. In output it even shows the new image name. But when listing revisions, I can see only the old one. Here is the example of the commands and outputs (shortened them a bit) I used to test this. Original image is "hellowreg.azurecr.io/helloworld:latest".

$ az containerapp update -g $RESOURCE_GROUP -n dapr-app-2 --image hellowreg.azurecr.io/helloworld:v2
Command group 'containerapp' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
{
  "configuration": {
    "activeRevisionsMode": "Multiple",

    ...
    ...

  "latestRevisionName": "dapr-app-2--services-revision",
  "location": "North Europe",
  "name": "dapr-app-2",
  "provisioningState": "Succeeded",
  "resourceGroup": "my-containerapps-us",

    ...
    ...

  "template": {
    "containers": [
      {
        "args": null,
        "command": null,
        "env": null,
        "image": "hellowreg.azurecr.io/helloworld:v2",
        "name": "service-2",
        "resources": {
          "cpu": 0.5,
          "memory": "1Gi"
        }
      }
    ],

    ...
    ...

    "revisionSuffix": "services-revision",
    "scale": {
      "maxReplicas": 2,
      "minReplicas": 1,
      "rules": null
    }
  },
  "type": "Microsoft.Web/containerApps"
}


$ az containerapp show -g $RESOURCE_GROUP -n dapr-app-2
Command group 'containerapp' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
{
  "configuration": {
    "activeRevisionsMode": "Multiple",

    ...
    ...
    ...


  "template": {
    "containers": [
      {
        "args": null,
        "command": null,
        "env": null,
        "image": "hellowreg.azurecr.io/helloworld:v2",
        "name": "service-2",
        "resources": {
          "cpu": 0.5,
          "memory": "1Gi"
        }
      }
    ],

    ...
    ...

    "revisionSuffix": "services-revision",
    "scale": {
      "maxReplicas": 2,
      "minReplicas": 1,
      "rules": null
    }
  },
  "type": "Microsoft.Web/containerApps"
}

$ az containerapp revision list -g $RESOURCE_GROUP -n dapr-app-2
Command group 'containerapp revision' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
[
  {
    "active": true,
    "createdTime": "2021-11-19T07:28:10+00:00",

    ...
    ...

    "location": "northeurope",
    "name": "dapr-app-2--services-revision",
    "provisioningError": null,
    "provisioningState": "Provisioned",
    "replicas": 1,
    "resourceGroup": "my-containerapps-us",
    "tags": null,
    "template": {
      "containers": [
        {
          "args": null,
          "command": null,
          "env": null,
          "image": "hellowreg.azurecr.io/helloworld:latest",
          "name": "service-2",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          }
        }

    ...
    ...

      "revisionSuffix": null,
      "scale": {
        "maxReplicas": 2,
        "minReplicas": 1,
        "rules": null
      }
    },
    "trafficWeight": 100,
    "type": "Microsoft.Web/containerapps/revisions"
  }
]

from azure-container-apps.

"a temporary work around is to always provide a revision suffix when updating the application"
it does not work

1- I've a revision 1 (rev-1) with 2 containers (A & B)
2- I've a revision 2 (rev without suffix) with 1 container (C)
3- if I create a revision 3 (rev-3) based on rev-1, it will be created based on rev 2 and container C, even if UI listed A & B

that's quite disturbing :)

from azure-container-apps.

@vturecek Hi any update on this issue ?

from azure-container-apps.

Hi @vturecek I ran into a similar issue.

• I create a new dotnet image and pushed it to ACR under the v1 tag

docker build \
		--platform=linux/amd64 \
		-f demoapp/Dockerfile \
		-t foobar..azurecr.io/demoapp:v1 .

• Then I created the container app pointing to the v1 tag

az containerapp create \
  --name my-demo-app \
  --resource-group $RESOURCE_GROUP \
  --image $CONTAINER_IMAGE_NAME:v1 \
  --environment $CONTAINERAPPS_ENVIRONMENT \
  --registry-server $REGISTRY_SERVER

• Then I made some code changes and re-built the docker image using the same v1 tag
• Then I updated the container app

az containerapp update \
      --name ${PROJ_CAPP_NAME} \
      --resource-group ${RESOURCE_GROUP} \
	  --image CONTAINER_IMAGE_NAME:v1

All commands succeeded with exit code 0. So no errors. But when I access my app on azure portal, it says the app is still in the older version with older timestamp.

Question: For each new revision is it mandatory to create a new docker image tag? Can we not reuse the tag like latest to create a new revision?

from azure-container-apps.

Thanks @anthonychu Good to know about revision restart and how change in env var can create new revisions.

Regarding tags, I will try to use a new tag for each push to ACR. The deeper problem is that there is no way to disallow overwriting an existing tag in ACR (see question). ACLs and locks are just workaround. This means sooner or later, a mis-configured ACL or RBAC could end-up overwriting an existing tag. For now, it would be helpful to have a clear message after az containerapp update if a new revision was created or not. I'll add my feedback to #182

from azure-container-apps.