Most Bugzilla attachments are highly-compressible text. Are they
currently stored in compressed form, and if not, would that be practical
to implement?
If feasible and not already implemented, this would vastly reduce
long-term storage requirements, at a CPU cost that could be made as low
as necessary by appropriate choice of algorithm and parameters.
– Ben Beasley
On 12/14/21 11:25, Carlos O'Donell wrote:
On 12/14/21 10:16, Robbie Harwood wrote:
Carlos O'Donell <carlos@xxxxxxxxxx> writes:
- Life-cycle management (delete attachments).
Please don't delete attachments. It severely reduces the usefulness of
keeping old bugzillas around - if we're going to do that, we might as
well delete the old bugzilla entries as well, and I don't think anyone
wants that.
I noted "life-cycle management" specifically so we could have a discussion about the
topic. Choosing one way or the other has costs and consequences. Without data from
bugzilla about the total size, growth rate of attachments, and cost of storage, it's
hard to decide on a real life-cycle policy.
To say "we must keep it all" needs some very specific qualification, because often
the older the bugzilla the less useful it is because it no longer matches existing
in-use code. Yes, it is nice for archaeology, but is it sufficiently nice that we
would prioritize it *over* the needs of Fedora users today to upload SOS reports?
Two positions could arise, given a fixed budget for storage:
(a) We keep attachments forever, but users can't upload SOS reports.
(b) We keep attachments for a reasonable amount of time, and users can upload SOS reports.
If I understand your data retention policy correctly it looks like this:
- Maximize usefulness.
- Priority is to existing and new <19.5MiB attachments?
- What about the priority to users and their ability to upload SOS reports?
- Consequence: Keep data forever and pay for that storage?
Do you have any thoughts on archiving attachments older than a certain age into
some kind of slow access / low cost / cold storage via a bugzilla URL attachment?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
