[Glass] Git based repositories (package-cache) problem when moving extent to another stone
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Oct 26 17:22:12 PDT 2015
I'm headed home
If the MCGitHubRepository class>>resetCacheDirectoryIfInvalid works for
a deleted directory (and you have found that that case works), then it
should work if th cache is explicitly cleared ...
HOWEVER, I recall that resetCacheDirectoryIfInvalid is triggered during
image startup, so perhaps there are additional initialization steps that
run at image startup ... perhaps the directory inst vars are nuked I
didn't look closely ... anyway take a look down that path and see if you
can find the additional inits that might be run at image startup (also
be suspicious of SessionTemps being used, since SessionTemps don't
survive across logins) ...
Dale
On 10/26/2015 05:09 PM, Mariano Martinez Peck wrote:
>
> On Mon, Oct 26, 2015 at 7:58 PM, Dale Henrichs via Glass
> <glass at lists.gemtalksystems.com
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>
>
> On 10/26/2015 03:03 PM, Mariano Martinez Peck via Glass wrote:
>
> Dale,
>
> I am finding problems with git-based repositories. Basically,
> let's say I load some stuff from git under the stone called
> 3.2.9. Then I copy the extent and I restore such a extent in
> another stone, called 'otherStone'.
>
> What scripts steps do you use when you"copy and restore in another
> stone" ....
>
>
> I do a snapshot with tODE then a cp of the extent.
>
>
>
> I now try to update code in my 'otherStone' and I get an
> exception while loading Seaside from metacello. The problem
> ends up being that in fact it is trying to get the stuff from
> here:
>
> '/opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'
>
> Ah okay ... I've been working with local clones of all of the
> projects (the mode that I think everyone should follow) ... the
> problem you are seeing has to do with using github:// repositories
> ... git repositories use filetree:// and the expectation is that
> you are moving extents within the same $GS_HOME environment ...
> nonetheless this should work ...
>
>
> Yes, the problem I found is when using github repos, not filetree (at
> least the error I had), and yes, using same $GS_HOME.
>
>
>
> All those files have a different OS owner and file
> permissiones etc etc.
>
> Of course, if I remove
> /opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache
> it suddenly starts to work in 'otherStone'.
>
> This seems to be a bug in MCGitHubRepository ... specifically
> MCGitHubRepository class>>resetCacheDirectoryIfInvalid will reset
> the CacheDirectory if it's no longer "valid" but it's test for
> "valid" is that the directory exists ... it should also worry
> about permissions ... I guess ... alternatively I could catch an
> error on access and reset the CacheDirectory and try again ... I
> don't know if there is platform independent protocol in Metacello
> for doing permission testing ... no quick fix there, I think ....
>
>
> Yes, that's exactly the point. In my case, the 'another' stone runs
> with a different OS user and hence there is a permission issue at file
> system level.
>
>
> In the mean time, you can clear the cache directory manually:
>
> MCGitHubRepository cacheDirectory: nil.
>
> If you are using $GS_HOME/bin/newExtent or
> $GS_HOME/bin/createStone with the `-t` option (which you should
> be), then newExtent ends up running the `rebuildServerTode` script:
>
> $GS_HOME/bin/todeIt $stoneName "script --script=rebuildServerTode"
>
> which itself runs
> $GS_HOME/sys/local/client/tode-scripts/rebuildSys ... whose job is
> to do things like make sure that the freshly copied extent is
> adapted correctly to it's new environment so I think that adding
> this line to the script would be correct:
>
> eval `MCGitHubRepository cacheDirectory: nil`
>
>
> Thanks. I just tried it but it seems it is not yet enough. Look at the
> exception I get:
>
> Inspect
> MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
> @31 line 39a GoferRepositoryError occurred (error 2710), a
> ImproperOperation occurred (error 2085), Expected nil to be a Boolean./
> --------------------
> . -> a GoferRepositoryError occurred (error 2710), a
> ImproperOperation occurred (error 2085), Expected nil to be a Boolean.
> .. -> aMetacelloEnsureFetchingMCSpecLoader(explicit load :
> 1.6 [ConfigurationOfIAM])
> (class)@ -> GoferRepositoryError
> (oop)@ -> 1767077889
> currGsHandler@ -> nil
> gsArgs@ -> nil
> gsDetails@ -> 'a ImproperOperation occurred (error 2085), Expected
> nil to be a Boolean.'
> gsNumber@ -> 2710
> gsReason@ -> nil
> gsResumable@ -> false
> gsStack@ -> nil
> gsTrappable@ -> true
> messageText@ -> 'a GoferRepositoryError occurred (error 2710), a
> ImproperOperation occurred (error 2085), Expected nil to be a Boolean.'
> repository@ ->
> aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)
> tag@ -> nil
>
>
> And when I inspect the 'repository' I get this:
>
> Inspect
> MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
> @31 line 39a GoferRepositoryError occurred (error 2710), a
> ImproperOperation occurred (error 2085), Expected nil to be a
> Boolean./aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)/
> --------------------
> . ->
> aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)
> .. -> a GoferRepositoryError occurred (error
> 2710), a ImproperOperation occurred (error 2085), Expected nil to be a
> Boolean.
> (class)@ -> MCGitHubRepository
> (oop)@ -> 1226322689
> (committed)@ -> true
> cache@ -> nil
> creationTemplate@ -> nil
> directory@ -> aServerFileDirectory
> projectPath@ -> 'GsDevKit/Seaside31'
> projectVersion@ -> 'v3.1.4.2-gs'
> projectVersionPattern@ -> '3.1.?'
> readonly@ -> true
> repoPath@ -> 'repository'
> repositoryProperties@ -> aDictionary( 'packageExtension'->'.package',
> 'propertyFileExtension'->'.json')
> storeDiffs@ -> nil
>
>
> And as you can see the problematic is that 'directory' instVar. if I
> send #pathName to it, I get:
>
> '/opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'
>
> I tried sending #flushCache to the repository instance, but not
> luck..the 'directory' instVar still there...
>
> Note that #flushCache of github class DOES nil the 'directory'
> instVar. However, this is funny:
>
> MCGitHubRepository cacheDirectory: nil.
> MCRepositoryGroup default repositoriesDo: [:rep | rep flushCache ].
> MCRepositoryGroup default repositoriesDo: [:each | (each
> projectVersion = 'v3.1.4.1-gs') ifTrue: [Halt halt] ].
>
> And then it halts... 'each' continues to have again the wrong value in
> 'directory'. Shouldn't this be nil? Of course I made sure the
> #flushCache was really sent to the repository.
>
> I don't get it.
>
> In fact, if you don't get there first, I'll submit a Metacello bug
> report, and then add this patch (along with a reference to the
> Metacello bug) to rebuildSys. I'm not planning a drop for a day or
> so, so if you want me to do the patch sooner, I can slipstream the
> patch into master and then create the bug and comment the patch
> with my next regular Early Access drop ...
>
> I might be inclined to think that patch actually belongs there ...
> when you move an extent ... all of the disk caches should be
> cleared ....
>
> Dale
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151026/7a1c513c/attachment.html>
More information about the Glass
mailing list