On Mon, Jul 2, 2018 at 12:09 PM Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
On Mon, Jul 2, 2018 at 5:04 PM Gerald B. Cox <gbcox@xxxxxx> wrote:On Mon, Jul 2, 2018 at 8:06 AM, Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:On Mon, Jul 2, 2018, 15:54 Gerald B. Cox <gbcox@xxxxxx> wrote:It appears to be a good idea, but when going through the readme, I found this:Please note that, while the code is pretty reliable and the file format shouldn't see any further changes, the API is still not fixed. Please do not use zchunk for any mission-critical systems yet.I would consider DNF to be a mission critical system. Shouldn't we wait until zchunk is deemedready? I don't understand how it is OK to use this for DNF, but it isn't OK for"any mission-critical systems".I would say that DNF must do proper fallback in which case if zchunk fails, DNF falls back to downloading full metadata. However, DNF does that do any out-of-process metadata handling which might crash it entirely (but I think we can fix such issues quickly).--I believe you're missing my point here... DNF should always do proper fallback - that wasn't the concern. The concern is why we are implementing a change to DNF using software thatby it's own admission should not be used for mission critical systems?Ah, you mean this. So the problem here is that there is no alternative to this here. There is casync, but it is not designed for this type of usage. Zchunk is good, but it's really dead.
Did you mean to write "Zchunk" here? Seems like it's contrary to your earlier statements. Maybe you meant a different project?
Gerald: I think the issue is that you wouldn't want to use zchunk in *actual* mission-critical operations (like transmitting air-traffic-control data). But for DNF, nothing in your system is going to misbehave if you get a few bad packets of metadata; the resulting file won't rebuild and it will need to be re-requested or fall back to the non-chunked download. In either case, I think this is safe.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/WVAYBTZH7BC3V5H2ZBX7NCAU2HC3J42L/
