Feature request - Create lifecycle feature for container registry [113559510]

Infeasible

Feature Request

Status Update

No update yet.

Description

mh...@dinkusa.com

created issue #1

Aug 30, 2018 07:45PM

Hi, it would be great if GCP offered a lifecycle feature in container registry like you do in cloud storage. The use case being that we have lots of images that we'll never use again. After even a week, we're unlikely to use some images ever again. It would be great to enable this feature so your users don't have to manually delete old images to save some money.

Comments

fa...@google.com <fa...@google.com> #2Aug 31, 2018 08:05PM

Assigned to gc...@google.com.

Triage notes: Assigning for a response.

em...@gmail.com <em...@gmail.com> #3Nov 17, 2019 11:34AM

When updating the providers, startProvider() is comparing the new scope produces with the previous scope produced, instead of the current parent scope, to determine if the content of the provider needs to change, ignoring if the parent changed. That has the effect of, if a provider provides a value that is identical to the parent value, the composer thinks that none of the the static composition locals changed and it doesn't need to force updates of the content of the provider.

The temporary work-around for this is to use a compositionLocalOf instead. Using compositionLocalOf is recommended for composition locals that can change and static should are not recommended for values that can change.

However, in the above example, LocalOtherValue only changes once so using a staticCompositionLocal is recommended as it avoids the overhead for tracking reads of a value that rarely changes, making this work-around temporary for LocalOtherValue or similar locals.

i....@dative.io <i....@dative.io> #4Dec 13, 2019 11:47AM

deleted

ii...@gmail.com <ii...@gmail.com> #5Jan 24, 2020 07:47AM

This issue also affects Material theming changes because they use staticCompositionLocalOf under the hood. And those cannot be changed by a work-around.

[Deleted User] <[Deleted User]> #6Feb 5, 2020 03:37PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Chuck Jazdzewski <chuckj@google.com>
Link: https://android-review.googlesource.com/3318540

Fixed providesDefault for a single provide

Expand for full commit details

Fixed `providesDefault` for a single provide 
 
If `providesDefault` is used as the sole provided value 
of a `CompostionLocalProvider` then the content of the 
provider may not update if a parent changes the value 
of a static composition local. Providing more than 
one value does not have this issue. 
 
Fixes: 374263387 
Test: new test, ./gradlew :compose:r:r:test 
Change-Id: Iabd4fbba6191abad4073ab5f302d252750683258

Files:

M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Composer.kt
M compose/runtime/runtime/src/nonEmulatorCommonTest/kotlin/androidx/compose/runtime/CompositionLocalTests.kt

Hash: b70a4268ba4985d4a5baf9c14edd81290d2ded1d
Date: Thu Oct 24 17:16:39 2024

an...@streem.com.au <an...@streem.com.au> #7Apr 14, 2020 01:23AM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.runtime:runtime:1.8.0-alpha06
androidx.compose.runtime:runtime-android:1.8.0-alpha06
androidx.compose.runtime:runtime-jvmstubs:1.8.0-alpha06
androidx.compose.runtime:runtime-linuxx64stubs:1.8.0-alpha06

pa...@mudafy.com <pa...@mudafy.com> #8Apr 24, 2020 09:03PM

Adding lifecycle rules such as "delete all images with no pull events in the last N days" and with extra conditions such as "(and|or) not in use in X GKE cluster" would be interesting. It could be a "Keep images in use during the last N days or by X[, Y, Z] GKE cluster(s)".

[Deleted User] <[Deleted User]> #9May 3, 2020 11:53AM

Is this feature include into the product roadmap? Is there a ETA?

[Deleted User] <[Deleted User]> #10Jun 8, 2020 08:23AM

This would allow us to replace house-in grown solutions, great initiative

[Deleted User] <[Deleted User]> #11Jun 25, 2020 02:25PM

+1
This will be really helpful

ju...@google.com <ju...@google.com> #12Jun 26, 2020 10:35PM

Hello, this feature is not available yet but it is in our roadmap (we'll update you as soon as we have an ETA). In the meantime, you can find information about tools that can help in this area in our documentation:

https://cloud.google.com/artifact-registry/docs/docker/copy-from-gcr#remove

[Deleted User] <[Deleted User]> #13Jun 29, 2020 12:06PM

de...@gmail.com <de...@gmail.com> #14Jul 3, 2020 08:50AM

jr...@glynndevins.com <jr...@glynndevins.com> #15Jul 9, 2020 09:53PM

[Deleted User] <[Deleted User]> #16Jul 27, 2020 10:50AM

r....@dotsource.de <r....@dotsource.de> #17Jul 30, 2020 11:38AM

da...@gmail.com <da...@gmail.com> #18Aug 2, 2020 08:50AM

[Deleted User] <[Deleted User]> #19Aug 7, 2020 10:24AM

ph...@hornbach.com <ph...@hornbach.com> #20Aug 18, 2020 12:56PM

el...@copyleaks.com <el...@copyleaks.com> #21Aug 19, 2020 09:33AM

[Deleted User] <[Deleted User]> #22Aug 21, 2020 02:47AM

ro...@gmail.com <ro...@gmail.com> #23Sep 10, 2020 09:10AM

zc...@google.com <zc...@google.com> #24Sep 10, 2020 07:20PM

z0...@gmail.com <z0...@gmail.com> #25Sep 18, 2020 09:53PM

Na...@bv-group.com <Na...@bv-group.com> #26Sep 21, 2020 09:05AM

Very relevant and required feature. not a new concept:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html

mo...@sky.uk <mo...@sky.uk> #27Sep 25, 2020 01:55PM

de...@g.globo <de...@g.globo> #28Sep 25, 2020 02:22PM

[Deleted User] <[Deleted User]> #29Sep 29, 2020 08:31AM

ma...@adaptable.io <ma...@adaptable.io> #30Sep 30, 2020 09:06PM

ai...@inniveinc.com <ai...@inniveinc.com> #31Oct 12, 2020 08:20AM

[Deleted User] <[Deleted User]> #32Oct 20, 2020 10:31PM

pm...@gmail.com <pm...@gmail.com> #33Oct 29, 2020 10:00PM

If you were to support this, please support it in the Artifact Registry too.

to...@hornbach.com <to...@hornbach.com> #34Nov 2, 2020 02:01PM

da...@apnic.net <da...@apnic.net> #35Dec 8, 2020 05:46AM

al...@gmail.com <al...@gmail.com> #36Dec 8, 2020 09:40AM

ko...@gmail.com <ko...@gmail.com> #37Dec 24, 2020 11:00AM

[Deleted User] <[Deleted User]> #38Jan 11, 2021 06:32PM

ma...@gmail.com <ma...@gmail.com> #39Feb 3, 2021 10:11AM

[Deleted User] <[Deleted User]> #40Feb 8, 2021 04:30AM

th...@gmail.com <th...@gmail.com> #41Feb 23, 2021 02:37AM

mi...@cesarine.com <mi...@cesarine.com> #42Feb 26, 2021 01:52PM

[Deleted User] <[Deleted User]> #43Mar 1, 2021 09:36PM

[Deleted User] <[Deleted User]> #44Mar 24, 2021 04:34AM

ro...@gmail.com <ro...@gmail.com> #45Apr 19, 2021 07:47AM

+1
Please!

ol...@gmail.com <ol...@gmail.com> #46Apr 21, 2021 06:52PM

Google seems to have no interest in this feature as the omission produces them a lot of extra money. Somebody would need to ship this to the news to make it happen.

[Deleted User] <[Deleted User]> #47May 19, 2021 04:11AM

It seems that i need to move on other cloud service.
Google need to think about this feature, why i use gcr cleaner or scrips else?

ni...@codecentric.de <ni...@codecentric.de> #48Jun 24, 2021 12:23PM

br...@richemont.com <br...@richemont.com> #49Jul 28, 2021 07:26AM

+1

the lack of this feature really impairs a good usage

va...@google.com <va...@google.com> #50Jul 30, 2021 07:21AM

Hello, the Product Team wanted to confirm that we are not adding this feature to Container Registry at this point. Artifact Registry is the recommended solution going forward, and this is where the team is focusing all the efforts (and where this feature will be implemented).

We encourage all users to migrate to Artifact Registry as it has more features.

Message last modified on Jul 30, 2021 07:22AM

di...@opsguru.io <di...@opsguru.io> #51Jul 30, 2021 09:50AM

It's a bit sad but there is a workaround:

https://github.com/sethvargo/gcr-cleaner

va...@google.com <va...@google.com> Jul 30, 2021 02:14PM

Status: Won't Fix (Infeasible)

kn...@goout.net <kn...@goout.net> #52Jul 30, 2021 02:28PM

Seriously?

[Deleted User] <[Deleted User]> #53Aug 11, 2021 12:17PM

So we are encouraged to use another new shinny service. But does this new service has this functionality? No. Then why would I do that?

du...@multiscale.io <du...@multiscale.io> #54Aug 11, 2021 03:13PM

I can�t believe we�re talking about this still years later. Artifact Registry doesn�t even have it, and the scripts we had for cleaning it don�t work anymore :D

From: buganizer-system@google.com <buganizer-system@google.com>
Date: Wednesday, August 11, 2021 at 7:17 AM
To: b-system+-330405182@google.com <b-system+-330405182@google.com>
Cc: duncan.bowring@multiscale.io <duncan.bowring@multiscale.io>
Subject: Re:

Issue 113559510

: Feature request - Create lifecycle feature for container registry
Replying to this email means your email address will be shared with the team that works on this product.

https://issuetracker.google.com/issues/113559510

Changed

yo...@solarmonkey.nl added

comment #53

https://issuetracker.google.com/issues/113559510#comment53>:
So we are encouraged to use another new shinny service. But does this new service has this functionality? No. Then why would I do that?

_______________________________

Reference Info: 113559510 Feature request - Create lifecycle feature for container registry
component: Public Trackers > Cloud Platform > Developer Tools > Container Registry & Artifact Registry<

https://issuetracker.google.com/components/187156>
status: Infeasible
reporter: mh...@dinkusa.com
assignee: gc...@google.com
cc: be...@google.com, fa...@google.com, jr...@google.com, and 1 more
type: Feature Request
priority: P2
severity: S2
blocked by: 36817144<

https://issuetracker.google.com/issues/36817144>, 113689022<

https://issuetracker.google.com/issues/113689022>
duplicate issue: 178219918<

https://issuetracker.google.com/issues/178219918>, 194488651<

https://issuetracker.google.com/issues/194488651>
retention: Component default

Generated by Google IssueTracker notification system

You're receiving this email because you are subscribed to updates on Google IssueTracker

issue 113559510

https://issuetracker.google.com/issues/113559510> where you have the role: starred.
Unsubscribe from this issue.<

https://issuetracker.google.com/issues/113559510?unsubscribe=true>

me...@kieranbenton.com <me...@kieranbenton.com> #55Sep 3, 2021 08:27AM

This is possibly a stupid question, but is there any reason why we couldn't just enable lifecycle rules on the GCS bucket that *backs* GCR to age out containers instead?

pe...@reedsy.com <pe...@reedsy.com> #56Sep 3, 2021 10:16AM

I'm not sure about this, but my guess is that the bucket doesn't store images individually; it's probably storing the individual layers instead. It could happen that an old layer is used by a recent image, so deleting an older layer could leave a recent image in an inconsistent state.

bi...@gmail.com <bi...@gmail.com> #57Sep 25, 2021 11:15AM

Regarding setting retention policies on the storage buckets themselves: "Note: Do not apply Cloud Storage retention policies to storage buckets used by Container Registry. These policies do not work for managing images in Container Registry storage buckets." as see here:

https://cloud.google.com/container-registry/docs/managing#deleting_images

I have not tried it but it doesn't look like that would work.

th...@monygroup.com <th...@monygroup.com> #58Nov 15, 2021 03:37PM

he...@mindoktor.se <he...@mindoktor.se> #59Dec 15, 2021 09:54AM

[Deleted User] <[Deleted User]> #60Dec 20, 2021 12:56PM

sa...@loblaw.ca <sa...@loblaw.ca> #61Jan 19, 2022 11:51PM

ru...@vida.com <ru...@vida.com> #62Jan 20, 2022 12:23AM

Since this ticket has been marked "Won't Fix (Infeasible)", due to it being targeted at Container Registry and not Artifact Registry, I've created a feature request specifically for Artifact Registry: https://issuetracker.google.com/issues/215403088

ak...@google.com <ak...@google.com> #63Feb 2, 2022 02:53AM

[Deleted User] <[Deleted User]> #64Feb 16, 2022 03:57PM

ju...@gmail.com <ju...@gmail.com> #65Feb 17, 2022 06:10PM

vi...@fabhotels.com <vi...@fabhotels.com> #66Apr 11, 2022 11:12AM

[Deleted User] <[Deleted User]> #67May 23, 2022 09:02PM

g....@xtribeapp.com <g....@xtribeapp.com> #68Jun 6, 2022 06:31AM

de...@wundermandata.com <de...@wundermandata.com> #69Jun 22, 2022 01:16AM

vm...@questrade.com <vm...@questrade.com> #70Jul 5, 2022 06:51AM

se...@listoglobal.com <se...@listoglobal.com> #71Jul 6, 2022 06:21PM

ja...@google.com <ja...@google.com> #72Aug 16, 2022 10:06PM

al...@malo.tech <al...@malo.tech> #73Sep 28, 2022 12:46AM

ol...@adorama.com <ol...@adorama.com> #74Oct 7, 2022 10:21AM

da...@passiolife.com <da...@passiolife.com> #75Oct 10, 2022 01:05PM

ga...@justpark.com <ga...@justpark.com> #76Nov 1, 2022 04:28PM

mi...@gmail.com <mi...@gmail.com> #77Jan 20, 2023 11:37AM

Comment has been deleted.

Message last modified on Jan 20, 2023 11:38AM