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 <car...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
