Tale must be restarted to see new versions

[craig-willis]

Problem
New versions do not appear in /versions mount until container is restarted.

Steps to Reproduce

1. Create tale
2. Launch tale
3. Edit something
4. Create version
5. Open terminal and ls ../versions
6. Restart tale
7. Open terminal and ls ../versions
8. Repeat steps 3-7

Expected Results
New versions are accessible from inside container without restarting

Actual Results
New versions are only accessible from inside container after restarting

[hategan]

I wonder if this is related to the modification time issue that you just filed with respect to image re-building.

What I know for sure is that ls will fail updating if the modification time is not properly updated.

[craig-willis]

@hategan I don't think this is the problem. In this case, the image was successfully built (the workspace modification time is only used for subsequent builds). With this issue, =when a new version is added via the API, GirderFS is not propagating the new version to the container.

[hategan]

GirderFS is not propagating the new version to the container.

GirderFS caches the /Versions directory. Every time it is accessed through FUSE, it checks, in sequence:

• if it's been recently loaded (i.e. loaded from Girder less than 1 second ago)
• if the modification time of /Versions as reported by Girder is the same as the modification time of the /Versions object fetched earlier

Only if both of the above tests fail, does GirderFS fetch a new listing of /Versions.
So, as I said, if the mtime is not being updated on the filesystem where /Versions is actually stored on the Girder side, ls /Versions will always return the same thing and never be updated.

[craig-willis]

OK, that makes sense. However, this mtime is different than the mtime used for image builds.

[craig-willis]

Testing this a while back, I thought this had been fixed by whole-tale/virtual_resources#10 but am again seeing the reported behavior. When I create a new version while the container is running, it does not appear via ls ../versions until the container is restarted.

[craig-willis]

Noting that this is currently also the case with version rename and delete operations.

[Xarthisius]

The issue here is that listing of version root is associated in girderfs cache with the Tale object. I guess https://github.com/whole-tale/girderfs/blob/master/girderfs/core.py#L1256 is biting us here...

As workaround we could call Tale().updateTale() every time something happens in versionRoot folder.

[hategan]

@Xarthisius, maybe. I'm looking at the rename() code and I can't see anything that updates the root folder, so I'm not sure using the versionRoot folder as root in GirderFS would make a difference.

But it may be wise to add a sequence number (or equivalent) to the tale.

[Xarthisius]

@Xarthisius, maybe. I'm looking at the rename() code and I can't see anything that updates the root folder, so I'm not sure using the versionRoot folder as root in GirderFS would make a difference.

But it may be wise to add a sequence number (or equivalent) to the tale.

Yeah, that was another thing we found today. I fixed that via whole-tale/wt_versioning#23 Now everything i.e. version folder, versions root folder and a tale, should be updated during rename.