[Glass] Git based repositories (package-cache) problem when moving extent to another stone
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Mon Oct 26 18:13:29 PDT 2015
Dale,
Do not continue loosing time until my next email. I found the
problem/solution but I don't have the time to explain and detail until
tomorrow.
Thanks!
On Mon, Oct 26, 2015 at 9:22 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:
> 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>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
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151026/c4d96b96/attachment-0001.html>
More information about the Glass
mailing list