You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's currently the seiso configmaps and seiso secrets feature.
The recent restructuring however looks very similar for both resource types: They watch the .metadata.creationTimestamp and .metadata.labels to decide whether to clean up objects. The internal logic is often reused for both resources.
However, those metadata is available to pretty much every object. I'd propose to use the dynamic client so that we can cleanup any kind of resources, even custom CRDs:
Image tags need somewhat more sophisticated logic (and for generic registries they don't have the same metatdata), there I would keep the current feature.
The text was updated successfully, but these errors were encountered:
With respect to the command's name, I'd suggest to use something else though, as "seiso" already has the meaning of "cleanup". Maybe seiso generic is just good enough. It would say, "clean up a generic resource" (as opposed to a container image).
I think the command usage is personal interpretation. Yes, Seiso means "cleanup" already so the second argument becomes redundant, but it could also be just regarded as the project name or binary name, and then the command usage feels more "english" and imperative when reading seiso, (please) cleanup secrets --older-than 1w.
But I have no hard feelings here, I'm fine with either.
There's currently the
seiso configmaps
andseiso secrets
feature.The recent restructuring however looks very similar for both resource types: They watch the
.metadata.creationTimestamp
and.metadata.labels
to decide whether to clean up objects. The internal logic is often reused for both resources.However, those metadata is available to pretty much every object. I'd propose to use the dynamic client so that we can cleanup any kind of resources, even custom CRDs:
Image tags need somewhat more sophisticated logic (and for generic registries they don't have the same metatdata), there I would keep the current feature.
The text was updated successfully, but these errors were encountered: