GS: Does temporary hold without retention policy prevent object deletion by lifecycle management?

[Kirill Katsnelson]

[Not strictly a GCE question, but there is no group for GS, and I've been hanging here and always got the most helpful answers.]

I have a bucket with no retention policy, but with lifecycle management rules, and one of these rules is set to delete objects in a year.

I want to keep a few objects from being deleted indefinitely. They are README files at the root level, describing what is stored there; therefore, an obvious answer "just put them in another bucket w/o lifecycle rules" would not work.

I placed a temporary hold on these objects. When I tried to delete them with gsutil, the hold prevented my attempt to delete them; so far so good. I also noticed that the hold did not prevent these to go Coldline by another lifetime rule (and the creation date changed to the date when the rule triggered), but I remember reading somewhere that the machinery behind the lifecycle management is not same as 'gsutil rewrite'.

The question: will the temporary hold prevent the deleting of the held objects by lifecycle rules, absent a retention policy?

Thanks,

 -kkm

[Elliott (Google Cloud Platform Support)]

Hello Kirill,

I have found a document here with some information. For event-based and temporary holds, “Both types of holds behave the same if the object is in a bucket that doesn't have a retention policy.”

Even if the bucket has a retention policy, the object will not be deleted. The type of hold will determine the behavior once released.

I hope this helps.

[Kirill Katsnelson]

Thanks you Elliot, and yes, I did read that piece of documentation before posting the question, and, IMO, it's not exactly reaching the point of being crystal clear; my doubt, still lingering after reading it, in the end, was what prompted me to ask this question. My feeling is that yes, the hold will absolutely prevent an object from being deleted, retention or not, by any mechanism (the 'gsutil rm' I already tried, and it does), but the wording is not 100% convincing, if you don't mind this tidbit of a feedback. The document appears to be focusing heavily on the retention (which I do not care about at all), and the holds are explained rather in passing in the overarching context of it.

The bucket is dedicated to the disaster recovery backups which, fingers crossed, would never be needed, but these README files are directions on the recovery process to the future me or whoever would have to do the recovery, so they better be available in an emergency.

I think I'll just experiment, time allowing, with a temporary bucket with the lifecycle set to delete everything in a day or two, and it will give me a definite answer.

And please do have great holidays! I'm surprised, and do indeed appreciate receiving your answer at this time of the year! :)

Cheers,

 -kkm

[George (Cloud Platform Support)]

Hello Kirill, 

How would you like to see wording improved, and made 100 % convincing? Retention is overly important to many customers, hence the importance it gets in the referred document. By contrast, you seem to refer to a special use-case: storing reminder-style information in a bucket normally affected by retention policy locks. How would wording in documentation cover both? A feature request needs the support of a well-motivated use-case to prove its point and convince. 

[Kirill Katsnelson]

George, Elliott, I'm sorry if I sounded too harsh. I did not mean to criticize the documentation for being too focused on retention; I understand, of course, that the retention machinery exists in the first place because customers want it. What I meant was, essentially, that my understanding of the docs was that I'm using one of the controls of the retention mechanism--and (again, in my initial reading) outside of its scope.

Perhaps, it would be helpful to simply mention the hold feature is the chapter title? "Retention policies, object holds and bucket lock"? The GCP can be really overwhelming, and when I read a piece of documentation, I necessarily put into a context of sub-sub-system X of subsystem Y of system Z. Thus, as far as I could reconstruct my initial understanding of the documentation about holds, it was like "wow, bullseye, looks like just what I need, but it's one of subfeatures of retention, and I am not using retention, so, hmm..." For me, it would be clear if the holds and retention were both the topic introduced by the title, kind of putting them on equal footing as two distinct, albeit closely related and cooperating features. But I'm just one of the million people who read the chapter, most of whom did not end up discombobulated.

When I just read the section again, it seemed clear, but it was not the same naive me who had been reading it the first time. One thing I'm 100% certain about is that it's impossible to write documentation to a system more complex than the retractable point pen that would be 100% convincing to anyone. And on second thought, I'm not even sure about the retractable pen. :)

Thank you for your help and and attention guys, sorry again about being too critical about the docs (they are in fact amazingly detailed), and please have a happy New Year!

 -kkm

[David Do]

Hello Kirill,

I have sent feedback on your behalf concerning the documentation you were referring to where a different title, like the one you suggested, would better represent the Bucket features that are being highlighted in that page. This should hopefully help readers understand what is being discussed without having to read the doc a second time.

Note that there is currently no ETA on the edit of that page.