2024-05-01 15:04:20 +00:00
|
|
|
This is a summary todo covering several subprojects, which would extend
|
|
|
|
git-annex to be able to use proxies which sit in front of a cluster of
|
|
|
|
repositories.
|
|
|
|
|
2024-05-01 16:19:12 +00:00
|
|
|
1. [[design/passthrough_proxy]]
|
2024-05-01 19:26:51 +00:00
|
|
|
2. [[design/p2p_protocol_over_http]]
|
|
|
|
3. [[design/balanced_preferred_content]]
|
|
|
|
4. [[todo/track_free_space_in_repos_via_git-annex_branch]]
|
|
|
|
5. [[todo/proving_preferred_content_behavior]]
|
2024-05-01 15:04:20 +00:00
|
|
|
|
2024-06-04 10:53:59 +00:00
|
|
|
Joey has received funding to work on this.
|
|
|
|
Planned schedule of work:
|
|
|
|
|
|
|
|
* June: git-annex proxy
|
|
|
|
* July, part 1: git-annex proxy support for exporttree
|
|
|
|
* July, part 2: p2p protocol over http
|
|
|
|
* August: balanced preferred content
|
|
|
|
* September: streaming through proxy to special remotes (especially S3)
|
|
|
|
* October: proving behavior of balanced preferred content with proxies
|
|
|
|
|
2024-05-01 15:04:20 +00:00
|
|
|
[[!tag projects/openneuro]]
|
2024-06-04 11:51:33 +00:00
|
|
|
|
|
|
|
# work notes
|
|
|
|
|
2024-06-04 18:55:54 +00:00
|
|
|
In development on the `proxy` branch.
|
|
|
|
|
2024-06-04 11:51:33 +00:00
|
|
|
For June's work on [[design/passthrough_proxy]], implementation plan:
|
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* UUID discovery via git-annex branch. Add a log file listing UUIDs
|
|
|
|
accessible via proxy UUIDs. It also will contain the names
|
|
|
|
of the remotes that the proxy is a proxy for,
|
|
|
|
from the perspective of the proxy. (done)
|
2024-06-04 18:55:54 +00:00
|
|
|
|
2024-06-14 19:23:43 +00:00
|
|
|
* Add `git-annex updateproxy` command (done)
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Remote instantiation for proxies. (done)
|
2024-06-04 18:55:54 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Implement git-annex-shell proxying to git remotes. (done)
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Proxy should update location tracking information for proxied remotes,
|
|
|
|
so it is available to other users who sync with it. (done)
|
2024-06-07 16:35:04 +00:00
|
|
|
|
2024-06-14 19:23:43 +00:00
|
|
|
* Implement `git-annex updatecluster` command (done)
|
|
|
|
|
2024-06-14 22:06:28 +00:00
|
|
|
* Implement cluster UUID insertation on location log load, and removal
|
|
|
|
on location log store. (done)
|
|
|
|
|
remove dead nodes when loading the cluster log
This is to avoid inserting a cluster uuid into the location log when
only dead nodes in the cluster contain the content of a key.
One reason why this is necessary is Remote.keyLocations, which excludes
dead repositories from the list. But there are probably many more.
Implementing this was challenging, because Logs.Location importing
Logs.Cluster which imports Logs.Trust which imports Remote.List resulted
in an import cycle through several other modules.
Resorted to making Logs.Location not import Logs.Cluster, and instead
it assumes that Annex.clusters gets populated when necessary before it's
called.
That's done in Annex.Startup, which is run by the git-annex command
(but not other commands) at early startup in initialized repos. Or,
is run after initialization.
Note that is Remote.Git, it is unable to import Annex.Startup, because
Remote.Git importing Logs.Cluster leads the the same import cycle.
So ensureInitialized is not passed annexStartup in there.
Other commands, like git-annex-shell currently don't run annexStartup
either.
So there are cases where Logs.Location will not see clusters. So it won't add
any cluster UUIDs when loading the log. That's ok, the only reason to do
that is to make display of where objects are located include clusters,
and to make commands like git-annex get --from treat keys as being located
in a cluster. git-annex-shell certainly does not do anything like that,
and I'm pretty sure Remote.Git (and callers to Remote.Git.onLocalRepo)
don't either.
2024-06-16 18:35:07 +00:00
|
|
|
* Omit cluster UUIDs when constructing drop proofs, since lockcontent will
|
|
|
|
always fail on a cluster. (done)
|
|
|
|
|
2024-06-16 19:07:48 +00:00
|
|
|
* Don't count cluster UUID as a copy. (done)
|
2024-06-14 22:06:28 +00:00
|
|
|
|
2024-06-17 13:31:44 +00:00
|
|
|
* Tab complete proxied remotes and clusters in eg --from option. (done)
|
2024-06-14 19:23:43 +00:00
|
|
|
|
2024-06-17 13:31:44 +00:00
|
|
|
* Basic proxying to special remote support (non-streaming).
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-14 19:23:43 +00:00
|
|
|
* Getting a key from a cluster should proxy from one of the nodes that has
|
checkpresent support for clusters
This assumes that the proxy for a cluster has up-to-date location
logs. If it didn't, it might proxy the checkpresent to a node that no
longer has the content, while some other node still does, and so
it would incorrectly appear that the cluster no longer contains the
content.
Since cluster UUIDs are not stored to location logs,
git-annex fsck --fast when claiming to fix a location log when
that occurred would not cause any problems. And presumably the location
tracking would later get sorted out.
At least usually, changes to the content of nodes goes via the proxy,
and it will update its location logs, so they will be accurate. However,
if there were multiple proxies to the same cluster, or nodes were
accessed directly (or via proxy to the node and not the cluster),
the proxy's location log could certainly be wrong.
(The location log access for GET has the same issues.)
2024-06-18 15:10:48 +00:00
|
|
|
it. (done)
|
2024-06-14 19:23:43 +00:00
|
|
|
|
2024-06-18 15:01:10 +00:00
|
|
|
* Getting a key from a cluster currently always selects the lowest cost
|
|
|
|
remote, and always the same remote if cost is the same. Should
|
|
|
|
round-robin amoung remotes, and prefer to avoid using remotes that
|
|
|
|
other git-annex processes are currently using.
|
|
|
|
|
2024-06-18 14:08:15 +00:00
|
|
|
* Implement upload with fanout and reporting back additional UUIDs over P2P
|
|
|
|
protocol.
|
|
|
|
|
2024-06-14 19:23:43 +00:00
|
|
|
* Implement cluster drops, trying to remove from all nodes, and returning
|
2024-06-18 14:08:15 +00:00
|
|
|
which UUIDs it was dropped from.
|
|
|
|
|
|
|
|
Problem: May lock content on cluster
|
|
|
|
nodes to satisfy numcopies (rather than locking elsewhere) and so not be
|
|
|
|
able to drop from nodes. Avoid using cluster nodes when constructing drop
|
|
|
|
proof for cluster.
|
|
|
|
|
|
|
|
Problem: When nodes are special remotes, may
|
|
|
|
treat nodes as copies while dropping from cluster, and so violate
|
|
|
|
numcopies. (But not mincopies.)
|
|
|
|
|
|
|
|
Problem: `move --from cluster` in "does this make it worse"
|
|
|
|
check may fail to realize that dropping from multiple nodes does in fact
|
|
|
|
make it worse.
|
2024-06-12 19:21:23 +00:00
|
|
|
|
checkpresent support for clusters
This assumes that the proxy for a cluster has up-to-date location
logs. If it didn't, it might proxy the checkpresent to a node that no
longer has the content, while some other node still does, and so
it would incorrectly appear that the cluster no longer contains the
content.
Since cluster UUIDs are not stored to location logs,
git-annex fsck --fast when claiming to fix a location log when
that occurred would not cause any problems. And presumably the location
tracking would later get sorted out.
At least usually, changes to the content of nodes goes via the proxy,
and it will update its location logs, so they will be accurate. However,
if there were multiple proxies to the same cluster, or nodes were
accessed directly (or via proxy to the node and not the cluster),
the proxy's location log could certainly be wrong.
(The location log access for GET has the same issues.)
2024-06-18 15:10:48 +00:00
|
|
|
* On upload to a cluster, as well as fanout to nodes, if the key is
|
|
|
|
preferred content of the proxy repository, store it there.
|
|
|
|
(But not when preferred content is not configured.)
|
|
|
|
And on download from a cluster, if the proxy repository has the content,
|
|
|
|
get it from there to avoid the overhead of proxying to a node.
|
|
|
|
|
2024-06-12 17:52:17 +00:00
|
|
|
* Support proxies-of-proxies better, eg foo-bar-baz.
|
|
|
|
Currently, it does work, but have to run `git-annex updateproxy`
|
|
|
|
on foo in order for it to notice the bar-baz proxied remote exists,
|
|
|
|
and record it as foo-bar-baz. Make it skip recording proxies of
|
|
|
|
proxies like that, and instead automatically generate those from the log.
|
|
|
|
(With cycle prevention there of course.)
|
|
|
|
|
2024-06-14 19:23:43 +00:00
|
|
|
* Cycle prevention including cluster-in-cluster cycles. See design.
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Optimise proxy speed. See design for ideas.
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Use `sendfile()` to avoid data copying overhead when
|
|
|
|
`receiveBytes` is being fed right into `sendBytes`.
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 15:55:18 +00:00
|
|
|
* Encryption and chunking. See design for issues.
|
2024-06-04 11:51:33 +00:00
|
|
|
|
2024-06-12 18:45:39 +00:00
|
|
|
* Indirect uploads (to be considered). See design.
|
2024-06-12 15:55:18 +00:00
|
|
|
|
|
|
|
* Support using a proxy when its url is a P2P address.
|
|
|
|
(Eg tor-annex remotes.)
|