Dale,
Thank you very much for the explanations. That helps me a lot.
The way I installed tODE was definitely unorthodox, and I know it's not fair to ask you to support non-standard installations, so don't feel pressured to fix my problems here. I'd just appreciate some general guidelines.
We've got lots of infrastructure built around the old way of running GLASS apps; the stone runs from /opt/gemstone/product/seaside and we have a number of helper scripts running from there. So I didn't want to dive head-on into the tODE-managed stone world if I didn't have to, and right now I'm trying to take baby steps into it. If I could continue to run my stone and scripts from the old tree, that'd be ideal… but if that's asking for trouble, I can give up on my ideals.
To load tODE, I first ran my repo through a full upgrade from 3.2.15 to 3.3.6 (upgradeImage, upgradeSeasideImage, etc). Then, I downloaded GsDevKit_home, ran the `installServer` script, and loaded the tODE code using Metacello. Here's the script I used:
#!/bin/bash -e
# Run as normal user with sudo privileges
export GEMSTONE=/opt/gemstone/product
export GEMSTONE_NAME=${GEMSTONE_NAME:-seaside}
export GS_HOME=/opt/gemstone/GsDevKit_home
export GS_SHARED_REPO="${GS_HOME}/shared/repos"
export GS_SHARED_REPO_TODE="<a href="filetree://${GS_SHARED_REPO}/tode/repository" class="">filetree://${GS_SHARED_REPO}/tode/repository"
sudo -u gsadmin -E $GEMSTONE/bin/topaz -lq <<EOF
set user DataCurator gems $GEMSTONE_NAME pass redacted
GsDeployer bulkMigrate: [
repository: '<a href="filetree://${GS_SHARED_REPO}/filetree/repository" class="">filetree://${GS_SHARED_REPO}/filetree/repository';
repository: '<a href="filetree://${GS_SHARED_REPO}/metacello-work/repository" class="">filetree://${GS_SHARED_REPO}/metacello-work/repository';
repository: '<a href="filetree://${GS_SHARED_REPO}/metacello-work/repository" class="">filetree://${GS_SHARED_REPO}/metacello-work/repository';
todeRepo := GsFile _expandEnvVariable: 'GS_SHARED_REPO_TODE' isClient: false.
show: '-----Install tODE using ', todeRepo.
GsDeployer bulkMigrate: [
onConflict: [:ex | ex disallow];
That all went fine, and at that point I was able to connect to the stone with a tODE client on my laptop via an SSH tunnel for the NetLDI port. Here's my session config:
TDSessionDescription {
#name : 'Production',
#stoneHost : 'localhost',
#stoneName : 'seaside',
#gemHost : 'localhost',
#netLDI : '',
#netLDIPort : '50380',
#gemTask : 'gemnetobject',
#userId : 'DataCurator',
#password : 'redacted',
#osUserId : nil,
#osPassword : nil,
#dataDirectory : nil,
#backupDirectory : '/opt/gemstone/product/seaside/data/backups/',
#snapshotDirectory : '/opt/gemstone/product/seaside/data/snapshots/',
#gemstoneVersion : '3.3.6',
#gciLibraryName : nil,
#adornmentColor : nil,
#serverGitRoot : nil,
#serverTodeRoot : '/opt/gemstone/GsDevKit_home',
#authorId : nil
}
But then, as you saw, I couldn't perform certain operations that needed to talk to the GsDevKit_home file tree. Is the #serverTodeRoot spec enough, or does the stone process on the server need tODE-specific environment variables, or are there some class vars that need to be set?
I couldn't figure out how to copy a stack from the tODE debugger, but I took a screenshot (attached). If I'm reading it right, my root node doesn't have a "sys" child at all… ?
--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221
On Feb 28, 2018, at 9:46 AM, Dale Henrichs via Glass <
[hidden email]> wrote:
On 02/27/2018 02:08 PM, Ken Treis via
Glass wrote:
I have an old 3.2.15 repository full of important data, and I
managed to (mostly) install tODE in it, but now I have lots of
(probably newbie) questions about tODE and Metacello Preview.
1. Are ConfigurationOf* classes obsolete? If so,
what replaces them? Most of the intro docs just talk about
baselines, which now live in separate classes — and often
separate packages — thus apparently disconnecting baseline specs
from version specs.
ConfigurationOf* are not obsolete. You see the emphasis on
BaselineOf, because I think that git/github is superior to
Monticello files for multi-developer open source projects. When a
project is stored in a git repository it is not necessary to record
the versions of the individual mcz files in the ConfigurationOf* (a
very tedious process) so the "version specs" aren't necessary.
It is still necessary to specify the package and project
dependencies so the BaselineOf was invented to specify only the
package/project dependencies....
tODE has been specifically designed to support a development model
based on git and github and I am in the process of converting all of
the projects used by GLASS/GsDevKit to GitHub and BaselineOf*.
ConfigurationOf* will continue to be supported "forever" however, I
want to encourage folks to move their projects to git, because the
ecosystem around git-based repositories continue to be improved.
2. Is it possible to load a specific version of
Seaside (in my case, 3.0.7.1) using tODE? Everything I'm reading
seems to be targeted at loading baselines.
For Seaside 3.0 I think that you can only use ConfigurationOf* ...
there are ways to create tODE project entires for ConfigurationOf*
projects[1], but I think that for ConfigurationOf* development you
should continue to use Metacello load expressions and custom
Smalltalk expressions. I would suggest that you create tODE scripts
using `touch sh <script-name>` for your load scripts and other
maintenance tasks. Ask questions on this list if you need some more
pointers.
[1]
https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/XMLSupport.ston
3. I'm able to connect to the old repository on my
(headless) server with both tODE and GemTools, but I can't seem
to `project install` Seaside:
Topez ERROR: a TodeCommandError occurred (error
121000), No such node: '/sys/local/server/projects/'
This error sees to be a case where the stone may not have been setup
correctly ... tODE expect there to be a "standard directory
structure in well known places" and this error seems to indicate
that perhaps there is a problem in this area ... could you give me
more details about how you "managed to (mostly) install tODE"
because perhaps you are hitting errors because of the "(mostly)"
bits ...
You can get a stack from a command error using `debugMode --set`
(see `debugMode -h` for more details) and the stack will help me
track down what is wrong ..
I've got a $GS_HOME/sys/local/server/projects
directory, both on the client and the server. Which of these is
the one that matters, and what do I have mis-configured such
that tODE can't find it? I tried both the `--local` and
`--stone` arguments to no avail.
These are all things that work when stones are created using the
GsDevKit_home `createStone` command, so I am wondering where you
might have departed from the standard installation ... "managed to
(mostly) install tODE" makes me wonder ...
Dale
Thanks in advance for help with any of these.
--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Locked
