Open discussion on Auto-Purge Policies design

[SteveLasker]

Please provide any feedback to the Auto-Purge design: here

[brobichaud]

This goes way beyond what I had anticipated for feature set and fully meets all of the scenario needs I had considered for our systems. So my comments are both "bravo", and "make it so!".

[powareverb]

Looks brilliant. Interested to know how exactly images would be marked under each policy (e.g. released). Possible API calls for this? PowerShell? 😁

[dany74q]

Looks awesome guys, great work !

[SteveLasker]

we haven't finalized the cli, but it would look something like: az acr purge-policy set --image foo:333 --policy 'release'
There will be an equivalent REST call as well.

[tgarlot]

Would that be possible to define the policy as what is done in Preview for storage (https://docs.microsoft.com/en-us/azure/storage/common/storage-lifecycle-managment-concepts) e.g. with a JSON payload? Would be great.

[Lampei]

Is there any kind of potential release roadmap to this feature? This also meets all of my scenarios for registry maintenance, so if it is a "coming very soon" vs. a coming 2020, then it would save me from rolling my own.

[SteveLasker]

Hi Lampei, we are actively working on Auto purge. We’ll have some of the basics for a recycle bin and purging un-tagged images. We hope to have the full spec done by Q1 of 2019.

[bpoland]

Hi there, this looks great. Any plans to include helm charts for automated cleanup, since ACR supports those too?

Thanks!

[SteveLasker]

Hi @brobichaud
Yup, we'll add these as well. Although, we'll have to think about this a bit more. We know an image is still running, to defer the image purge for [configured days] past the last known usage. For images, we plan to monitor all managed nodes in Azure to report back the image is still in use.
Helm charts are a bit different. Once a chart is used to do a deployment, it may continue to run for 6 months. If the policy is 6 months, and the chart hadn't been used for 6 months, what happens on 6 months and a day, when you may need to do a new chart deployment.
We'll think more and update in January.
Thanks for the issue. It's a great catch.
Happy holidays,
Steve

[phil-lgr]

I'm heavily using the Azure UIs, the CLI not so much—setting the policies via a UI in Azure would be much appreciated

[SteveLasker]

Thanks Phil,
Yup, we’ll have UI for these as well.

[bpoland]

Helm charts are a bit different. Once a chart is used to do a deployment, it may continue to run for 6 months. If the policy is 6 months, and the chart hadn't been used for 6 months, what happens on 6 months and a day, when you may need to do a new chart deployment.

Hi @SteveLasker,

Not sure how in-depth AKS can get but I believe Helm info is stored as ConfigMaps inside of Kubernetes. So there would probably be a way to check that and figure out whether a chart is still in use.

[jeffbeagley]

We use an auto incrementing build ID generated from Azure Pipelines, so we needed a quick way just to purge older images based on the tag ID. I wrote this quick shell script to purge images older than the 10th image. Could easily be modified just to require a "delete before x date" reference.

https://github.com/jeffbeagley/azure_cr_purge/blob/master/retention.sh

I believe an ideal retention policy would follow a behavior similiar to
purge where (tagCount>10 && timestamp <=time_retention) so that you can still maintain images in order to rollback regardless of how long its been since that image has been developed against