2012-08-22 18:32:17 +00:00
|
|
|
{- git-annex assistant repo syncing
|
|
|
|
-
|
|
|
|
- Copyright 2012 Joey Hess <joey@kitenet.net>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Assistant.Sync where
|
|
|
|
|
|
|
|
import Assistant.Common
|
|
|
|
import Assistant.Pushes
|
2012-11-03 18:16:17 +00:00
|
|
|
import Assistant.NetMessager
|
|
|
|
import Assistant.Types.NetMessager
|
2012-08-22 18:32:17 +00:00
|
|
|
import Assistant.Alert
|
2013-04-04 05:48:26 +00:00
|
|
|
import Assistant.Alert.Utility
|
2012-08-22 18:32:17 +00:00
|
|
|
import Assistant.DaemonStatus
|
|
|
|
import Assistant.ScanRemotes
|
|
|
|
import qualified Command.Sync
|
|
|
|
import Utility.Parallel
|
|
|
|
import qualified Git
|
|
|
|
import qualified Git.Branch
|
|
|
|
import qualified Git.Command
|
|
|
|
import qualified Remote
|
2012-09-04 19:54:30 +00:00
|
|
|
import qualified Types.Remote as Remote
|
2012-08-22 18:32:17 +00:00
|
|
|
import qualified Annex.Branch
|
2012-09-16 23:48:12 +00:00
|
|
|
import Annex.UUID
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
import Annex.TaggedPush
|
2012-08-22 18:32:17 +00:00
|
|
|
|
|
|
|
import Data.Time.Clock
|
|
|
|
import qualified Data.Map as M
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
import qualified Data.Set as S
|
2012-09-11 01:55:59 +00:00
|
|
|
import Control.Concurrent
|
2012-08-22 18:32:17 +00:00
|
|
|
|
|
|
|
{- Syncs with remotes that may have been disconnected for a while.
|
|
|
|
-
|
2012-08-23 19:22:23 +00:00
|
|
|
- First gets git in sync, and then prepares any necessary file transfers.
|
|
|
|
-
|
scan multiple remotes in one pass
The expensive transfer scan now scans a whole set of remotes in one pass.
So at startup, or when network comes up, it will run only once.
Note that this can result in transfers from/to higher cost remotes being
queued before other transfers of other content from/to lower cost remotes.
Before, low cost remotes were scanned first and all their transfers came
first. When multiple transfers are queued for a key, the lower cost ones
are still queued first. However, this could result in transfers from slow
remotes running for a long time while transfers of other data from faster
remotes waits.
I expect to make the transfer queue smarter about ordering
and/or make it allow multiple transfers at a time, which should eliminate
this annoyance. (Also, it was already possible to get into that situation,
for example if the network was up, lots of transfers from slow remotes
might be queued, and then a disk is mounted and its faster transfers have
to wait.)
Also note that this means I don't need to improve the code in
Assistant.Sync that currently checks if any of the reconnected remotes
have diverged, and if so, queues scans of all of them. That had been very
innefficient, but now doesn't matter.
2012-08-26 18:01:43 +00:00
|
|
|
- An expensive full scan is queued when the git-annex branches of some of
|
|
|
|
- the remotes have diverged from the local git-annex branch. Otherwise,
|
2012-08-23 19:22:23 +00:00
|
|
|
- it's sufficient to requeue failed transfers.
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
-
|
|
|
|
- XMPP remotes are also signaled that we can push to them, and we request
|
|
|
|
- they push to us. Since XMPP pushes run ansynchronously, any scan of the
|
|
|
|
- XMPP remotes has to be deferred until they're done pushing to us, so
|
|
|
|
- all XMPP remotes are marked as possibly desynced.
|
2012-08-22 18:32:17 +00:00
|
|
|
-}
|
2012-10-29 20:22:14 +00:00
|
|
|
reconnectRemotes :: Bool -> [Remote] -> Assistant ()
|
|
|
|
reconnectRemotes _ [] = noop
|
|
|
|
reconnectRemotes notifypushes rs = void $ do
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
modifyDaemonStatus_ $ \s -> s
|
|
|
|
{ desynced = S.union (S.fromList $ map Remote.uuid xmppremotes) (desynced s) }
|
2013-03-18 20:19:42 +00:00
|
|
|
syncAction rs (const go)
|
2012-10-30 23:33:27 +00:00
|
|
|
where
|
|
|
|
gitremotes = filter (notspecialremote . Remote.repo) rs
|
2013-03-18 20:19:42 +00:00
|
|
|
(xmppremotes, nonxmppremotes) = partition isXMPPRemote rs
|
2012-10-30 23:33:27 +00:00
|
|
|
notspecialremote r
|
|
|
|
| Git.repoIsUrl r = True
|
|
|
|
| Git.repoIsLocal r = True
|
2013-03-18 20:19:42 +00:00
|
|
|
| Git.repoIsLocalUnknown r = True
|
2012-10-30 23:33:27 +00:00
|
|
|
| otherwise = False
|
|
|
|
sync (Just branch) = do
|
2013-03-18 20:19:42 +00:00
|
|
|
(failedpull, diverged) <- manualPull (Just branch) gitremotes
|
2012-10-30 23:33:27 +00:00
|
|
|
now <- liftIO getCurrentTime
|
2013-03-18 20:19:42 +00:00
|
|
|
failedpush <- pushToRemotes' now notifypushes gitremotes
|
|
|
|
return (nub $ failedpull ++ failedpush, diverged)
|
2012-10-30 23:33:27 +00:00
|
|
|
{- No local branch exists yet, but we can try pulling. -}
|
2013-03-18 20:19:42 +00:00
|
|
|
sync Nothing = manualPull Nothing gitremotes
|
2013-03-06 20:29:19 +00:00
|
|
|
go = do
|
2013-03-18 20:19:42 +00:00
|
|
|
(failed, diverged) <- sync
|
2013-03-06 20:29:19 +00:00
|
|
|
=<< liftAnnex (inRepo Git.Branch.current)
|
2013-03-06 21:43:55 +00:00
|
|
|
addScanRemotes diverged nonxmppremotes
|
2013-03-18 20:19:42 +00:00
|
|
|
return failed
|
2012-08-22 18:32:17 +00:00
|
|
|
|
|
|
|
{- Updates the local sync branch, then pushes it to all remotes, in
|
2012-09-16 23:48:12 +00:00
|
|
|
- parallel, along with the git-annex branch. This is the same
|
|
|
|
- as "git annex sync", except in parallel, and will co-exist with use of
|
|
|
|
- "git annex sync".
|
2012-08-22 18:32:17 +00:00
|
|
|
-
|
2012-11-09 18:34:06 +00:00
|
|
|
- After the pushes to normal git remotes, also signals XMPP clients that
|
|
|
|
- they can request an XMPP push.
|
2012-11-08 23:41:36 +00:00
|
|
|
-
|
2012-08-22 18:32:17 +00:00
|
|
|
- Avoids running possibly long-duration commands in the Annex monad, so
|
2012-09-16 23:48:12 +00:00
|
|
|
- as not to block other threads.
|
|
|
|
-
|
|
|
|
- This can fail, when the remote's sync branch (or git-annex branch) has
|
|
|
|
- been updated by some other remote pushing into it, or by the remote
|
|
|
|
- itself. To handle failure, a manual pull and merge is done, and the push
|
|
|
|
- is retried.
|
|
|
|
-
|
|
|
|
- When there's a lot of activity, we may fail more than once.
|
|
|
|
- On the other hand, we may fail because the remote is not available.
|
|
|
|
- Rather than retrying indefinitely, after the first retry we enter a
|
|
|
|
- fallback mode, where our push is guarenteed to succeed if the remote is
|
|
|
|
- reachable. If the fallback fails, the push is queued to be retried
|
|
|
|
- later.
|
2013-03-18 20:19:42 +00:00
|
|
|
-
|
|
|
|
- Returns any remotes that it failed to push to.
|
2012-09-16 23:48:12 +00:00
|
|
|
-}
|
2013-03-18 20:19:42 +00:00
|
|
|
pushToRemotes :: Bool -> [Remote] -> Assistant [Remote]
|
2013-03-06 21:54:45 +00:00
|
|
|
pushToRemotes notifypushes remotes = do
|
2013-03-18 20:19:42 +00:00
|
|
|
now <- liftIO getCurrentTime
|
|
|
|
syncAction remotes (pushToRemotes' now notifypushes)
|
|
|
|
pushToRemotes' :: UTCTime -> Bool -> [Remote] -> Assistant [Remote]
|
2013-03-06 21:54:45 +00:00
|
|
|
pushToRemotes' now notifypushes remotes = do
|
2012-10-29 20:22:14 +00:00
|
|
|
(g, branch, u) <- liftAnnex $ do
|
2012-10-28 19:33:21 +00:00
|
|
|
Annex.Branch.commit "update"
|
|
|
|
(,,)
|
|
|
|
<$> gitRepo
|
|
|
|
<*> inRepo Git.Branch.current
|
|
|
|
<*> getUUID
|
2012-11-09 18:34:06 +00:00
|
|
|
let (xmppremotes, normalremotes) = partition isXMPPRemote remotes
|
2012-11-10 16:18:00 +00:00
|
|
|
ret <- go True branch g u normalremotes
|
|
|
|
forM_ xmppremotes $ \r ->
|
|
|
|
sendNetMessage $ Pushing (getXMPPClientID r) CanPush
|
|
|
|
return ret
|
2012-10-29 20:22:14 +00:00
|
|
|
where
|
2013-03-18 20:19:42 +00:00
|
|
|
go _ Nothing _ _ _ = return [] -- no branch, so nothing to do
|
|
|
|
go _ _ _ _ [] = return [] -- no remotes, so nothing to do
|
2012-10-29 20:22:14 +00:00
|
|
|
go shouldretry (Just branch) g u rs = do
|
|
|
|
debug ["pushing to", show rs]
|
|
|
|
liftIO $ Command.Sync.updateBranch (Command.Sync.syncBranch branch) g
|
|
|
|
(succeeded, failed) <- liftIO $ inParallel (push g branch) rs
|
|
|
|
updatemap succeeded []
|
|
|
|
if null failed
|
|
|
|
then do
|
|
|
|
when notifypushes $
|
2012-11-03 18:16:17 +00:00
|
|
|
sendNetMessage $ NotifyPush $
|
|
|
|
map Remote.uuid succeeded
|
2013-03-18 20:19:42 +00:00
|
|
|
return failed
|
2012-10-29 20:22:14 +00:00
|
|
|
else if shouldretry
|
|
|
|
then retry branch g u failed
|
|
|
|
else fallback branch g u failed
|
2012-08-22 18:32:17 +00:00
|
|
|
|
2012-10-29 21:52:43 +00:00
|
|
|
updatemap succeeded failed = changeFailedPushMap $ \m ->
|
|
|
|
M.union (makemap failed) $
|
|
|
|
M.difference m (makemap succeeded)
|
2012-10-29 20:22:14 +00:00
|
|
|
makemap l = M.fromList $ zip l (repeat now)
|
2012-08-22 18:32:17 +00:00
|
|
|
|
2012-10-29 20:22:14 +00:00
|
|
|
retry branch g u rs = do
|
|
|
|
debug ["trying manual pull to resolve failed pushes"]
|
2012-10-29 20:28:45 +00:00
|
|
|
void $ manualPull (Just branch) rs
|
2012-10-29 20:22:14 +00:00
|
|
|
go False (Just branch) g u rs
|
2012-09-16 23:48:12 +00:00
|
|
|
|
2012-10-29 20:22:14 +00:00
|
|
|
fallback branch g u rs = do
|
|
|
|
debug ["fallback pushing to", show rs]
|
|
|
|
(succeeded, failed) <- liftIO $
|
2013-03-06 20:29:19 +00:00
|
|
|
inParallel (\r -> taggedPush u Nothing branch r g) rs
|
2012-10-29 20:22:14 +00:00
|
|
|
updatemap succeeded failed
|
|
|
|
when (notifypushes && (not $ null succeeded)) $
|
2012-11-03 18:16:17 +00:00
|
|
|
sendNetMessage $ NotifyPush $
|
|
|
|
map Remote.uuid succeeded
|
2013-03-18 20:19:42 +00:00
|
|
|
return failed
|
2012-10-29 20:22:14 +00:00
|
|
|
|
|
|
|
push g branch remote = Command.Sync.pushBranch remote branch g
|
2012-11-10 18:38:50 +00:00
|
|
|
|
2013-03-18 20:19:42 +00:00
|
|
|
{- Displays an alert while running an action that syncs with some remotes,
|
|
|
|
- and returns any remotes that it failed to sync with.
|
|
|
|
-
|
|
|
|
- XMPP remotes are handled specially; since the action can only start
|
|
|
|
- an async process for them, they are not included in the alert, but are
|
|
|
|
- still passed to the action.
|
2013-03-28 18:51:39 +00:00
|
|
|
-
|
|
|
|
- Readonly remotes are also hidden (to hide the web special remote).
|
2013-03-18 20:19:42 +00:00
|
|
|
-}
|
|
|
|
syncAction :: [Remote] -> ([Remote] -> Assistant [Remote]) -> Assistant [Remote]
|
|
|
|
syncAction rs a
|
2013-03-28 18:51:39 +00:00
|
|
|
| null visibleremotes = a rs
|
2013-03-18 20:19:42 +00:00
|
|
|
| otherwise = do
|
2013-03-28 18:51:39 +00:00
|
|
|
i <- addAlert $ syncAlert visibleremotes
|
2013-03-18 20:19:42 +00:00
|
|
|
failed <- a rs
|
2013-03-27 18:19:10 +00:00
|
|
|
let failed' = filter (not . Git.repoIsLocalUnknown . Remote.repo) failed
|
2013-03-28 18:51:39 +00:00
|
|
|
let succeeded = filter (`notElem` failed) visibleremotes
|
2013-03-27 18:25:49 +00:00
|
|
|
if null succeeded && null failed'
|
|
|
|
then removeAlert i
|
|
|
|
else updateAlertMap $ mergeAlert i $
|
|
|
|
syncResultAlert succeeded failed'
|
2013-03-18 20:19:42 +00:00
|
|
|
return failed
|
|
|
|
where
|
2013-03-28 18:51:39 +00:00
|
|
|
visibleremotes = filter (not . Remote.readonly) $
|
|
|
|
filter (not . isXMPPRemote) rs
|
2013-03-18 20:19:42 +00:00
|
|
|
|
|
|
|
{- Manually pull from remotes and merge their branches. Returns any
|
|
|
|
- remotes that it failed to pull from, and a Bool indicating
|
|
|
|
- whether the git-annex branches of the remotes and local had
|
|
|
|
- diverged before the pull.
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
-
|
2013-03-18 20:19:42 +00:00
|
|
|
- After pulling from the normal git remotes, requests pushes from any
|
|
|
|
- XMPP remotes. However, those pushes will run asynchronously, so their
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
- results are not included in the return data.
|
|
|
|
-}
|
2013-03-18 20:19:42 +00:00
|
|
|
manualPull :: Maybe Git.Ref -> [Remote] -> Assistant ([Remote], Bool)
|
2012-10-29 20:28:45 +00:00
|
|
|
manualPull currentbranch remotes = do
|
|
|
|
g <- liftAnnex gitRepo
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
let (xmppremotes, normalremotes) = partition isXMPPRemote remotes
|
2013-03-18 20:19:42 +00:00
|
|
|
failed <- liftIO $ forM normalremotes $ \r ->
|
|
|
|
ifM (Git.Command.runBool [Param "fetch", Param $ Remote.name r] g)
|
|
|
|
( return Nothing
|
|
|
|
, return $ Just r
|
|
|
|
)
|
2012-10-29 20:28:45 +00:00
|
|
|
haddiverged <- liftAnnex Annex.Branch.forceUpdate
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
forM_ normalremotes $ \r ->
|
2012-10-29 20:28:45 +00:00
|
|
|
liftAnnex $ Command.Sync.mergeRemote r currentbranch
|
assistant: Get back in sync with XMPP remotes after network reconnection, and on startup.
Make manualPull send push requests over XMPP.
When reconnecting with remotes, those that are XMPP remotes cannot
immediately be pulled from and scanned, so instead maintain a set of
(probably) desynced remotes, and put XMPP remotes on it. (This set could be
used in other ways later, if we can detect we're out of sync with other
types of remotes.)
The merger handles detecting when a XMPP push is received from a desynced
remote, and triggers a scan then, if they have in fact diverged.
This has one known bug: A single XMPP remote can have multiple clients
behind it. When this happens, only the UUID of one client is recorded
as the UUID of the XMPP remote. Pushes from the other XMPP clients will not
trigger a scan. If the client whose UUID is expected responds to the push
request, it'll work, but when that client is offline, we're SOL.
2013-03-06 19:09:31 +00:00
|
|
|
forM_ xmppremotes $ \r ->
|
|
|
|
sendNetMessage $ Pushing (getXMPPClientID r) PushRequest
|
2013-03-18 20:19:42 +00:00
|
|
|
return (catMaybes failed, haddiverged)
|
2012-09-11 01:55:59 +00:00
|
|
|
|
2013-04-08 19:36:09 +00:00
|
|
|
{- Start syncing a remote, using a background thread. -}
|
|
|
|
syncRemote :: Remote -> Assistant ()
|
|
|
|
syncRemote remote = do
|
2012-10-30 19:39:15 +00:00
|
|
|
updateSyncRemotes
|
2012-10-30 23:12:05 +00:00
|
|
|
thread <- asIO $ do
|
|
|
|
reconnectRemotes False [remote]
|
2012-12-06 21:15:45 +00:00
|
|
|
addScanRemotes True [remote]
|
2012-10-30 23:12:05 +00:00
|
|
|
void $ liftIO $ forkIO $ thread
|