Container group cannot be updated about aci-deploy HOT 9 OPEN

I understand your concern @roncsak . Thanks a lot for explaining it with all details.
As of now, the requirement of these parameters is mandatory by design. To address your concern regarding ease of usage, we'll consider this enhancement. Can't promise a date yet, will have to see when can this be prioritized.
Meanwhile, feel free to contribute and raise a PR. Contributions are most welcome!

from aci-deploy.

I had the same problem. The cause was, that when creting container instances I used non-default values for RAM nad the aci-deploy action has default values on these params and these values were different, therefore Azure thinks "Oh hey, you are trying add more memory? No way without delete." So the solution was to specify these optional params in pipeline and set them to the same values as in Container Instances.

It also updated my secure env variables. I have some secrets there, so I can't specify it in pipeline. It could be resolved adding them to Gihtub Secrets probably, but I'd prefer not to have specify them at all.

from aci-deploy.

This issue is idle because it has been open for 14 days with no activity.

from aci-deploy.

Thanks for your insights @HonzaV
@roncsak Were you able to make progress?

from aci-deploy.

Hello @kanika1894,
if you read carefully, @HonzaV confirms the issue and the workaround I had, too.
I see only two options viable:

• Make cpu, memory, restart-policy mandatory
• Let cpu, memory, restart-policy optional and aci-deploy should know that it is currently updating an ACI or creating a new one. Upon creating a new one, use default values (in case not provided) to create ACI but check set values of created ACI upon updating.

The latter one would be the ultimate solution.

from aci-deploy.

This issue is idle because it has been open for 14 days with no activity.

from aci-deploy.

Hey @roncsak,

The default values for cpu, memory and restart-policy are given for the scenario when the user deploys a new container from the workflow itself.
The error The updates on container group 'mycontainer' are invalid. If you are going to update the os type, restart policy, network profile, CPU, memory, or GPU resources for a container group, you must delete it first and then create a new one. comes when a user is trying to update an existing container with a new image(having different values for the specified parameters). Also, if the update is except these image parameters, say, while updating dns-name-label, this won't come.

This is in sync with the fact that changes in certain properties require deletion and redeployment. Please refer this doc for more information.

from aci-deploy.

Hey @kanika1894,
that's the very thing that I don't want to!

Just look at the example code written here.

        - name: 'Deploy to Azure Container Instances'
          uses: 'azure/aci-deploy@v1'
          with:
            resource-group: contoso
            dns-name-label: url-for-container
            image: contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
            registry-username: ${{ secrets.REGISTRY_USERNAME }}
            registry-password: ${{ secrets.REGISTRY_PASSWORD }}
            name: contoso-container
            location: 'west us'

Do you see? Even the example code omits the usage of cpu, memory and restart-plocy.

So what happens if an infastructure guy creates a Container Instance beforehand with 2 vcpu and 2 GB memory?
This example code will fail because this GH Action will pass default values of those attributes!
The problem is, that a regular developer shouldn't care about how much cpu and memory this resource has. If developers want to change the image only, they shouldn't care providing cpu and memory.
Operations will monitor the resource and they will act if needed.

The very simple problem with this action that it provides default values for some attributes (e.g. cpu and memory) even if the Container Instance is already created!
It could be easily fixed as I wrote in the original post.

from aci-deploy.

This issue is idle because it has been open for 14 days with no activity.

from aci-deploy.