Bug 814031 - Force correct local directory ordering in local snapshot trees
Force correct local directory ordering in local snapshot trees
Status: CLOSED NEXTRELEASE
Product: PulpDist
Classification: Community
Component: Pulp Plugins (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity medium
: 0.2.0
: ---
Assigned To: Nick Coghlan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-19 00:41 EDT by Nick Coghlan
Modified: 2012-05-25 03:09 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-25 03:09:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nick Coghlan 2012-04-19 00:41:06 EDT
Local snapshot tree behaviour is sensitive to the relative mtimes of the local trees. Currently, the tree consolidation (via hardlink) is disabled for snapshot trees due to the possible effect on these mtimes.

If the *remote* mtimes were made available to the consolidation step, it could make a subsequent pass to ensure the relative ordering of the local directory mtimes was correct.

Alternatively, once the plugins are updated to store tree metadata in the Pulp repository, those records could be used to perform the ordering step, meaning the snapshot sync algorithm would no longer misbehave when local directories are modified unexpectedly.

The latter is probably the more robust solution - the case of a directory being deleted from the filesystem without removing it from the metadata can be handled just by logging the event and updating the metadata on the fly.
Comment 1 Nick Coghlan 2012-05-25 03:09:57 EDT
After further investigation, I realised this could be resolved by updating the latest symlink every time a new tree is fetched. That way, it will naturally be left pointing to the most recently downloaded tree, regardless of what happens to the local mtimes after the download is complete.

This approach has been implemented for 0.0.16

Note You need to log in before you can comment on or make changes to this bug.