Bug 814031

Summary: Force correct local directory ordering in local snapshot trees
Product: [Community] PulpDist Reporter: Nick Coghlan <ncoghlan>
Component: Pulp PluginsAssignee: Nick Coghlan <ncoghlan>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecified   
Target Milestone: 0.2.0   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-25 07:09:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nick Coghlan 2012-04-19 04:41:06 UTC
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 07:09:57 UTC
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