[
https://issues.apache.org/jira/browse/MESOS-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044841#comment-15044841
]
Bernd Mathiske commented on MESOS-2073:
---------------------------------------
Since there was no reply on the dev and user list as to how the fetcher cache
is being used and what features would be best to extend its feature set,
especially mtime-based cache entry invalidation, let's deprioritize this topic
for now.
> Fetcher cache file verification, updating and invalidation
> ----------------------------------------------------------
>
> Key: MESOS-2073
> URL: https://issues.apache.org/jira/browse/MESOS-2073
> Project: Mesos
> Issue Type: Epic
> Components: fetcher, slave
> Reporter: Bernd Mathiske
> Priority: Minor
> Labels: mesosphere
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> The other tickets in the fetcher cache epic do not necessitate a check sum
> (e.g. MD5, SHA*) for files cached by the fetcher. Whereas such a check sum
> could be used to verify whether the file arrived without unintended
> alterations, it can first and foremost be employed to detect and trigger
> updates.
> Scenario: If a UIR is requested for fetching and the indicated download has
> the same check sum as the cached file, then the cache file will be used and
> the download forgone. If the check sum is different, then fetching proceeds
> and the cached file gets replaced.
> This capability will be indicated by an additional field in the URI protobuf.
> Details TBD, i.e. to be discussed in comments below.
> In addition to the above, even if the check sum is the same, we can support
> voluntary cache file invalidation: a fresh download can be requested, or the
> caching behavior can be revoked entirely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
