[Glass] Can we move locks to inside GsDevKit_home ?

[Dale Henrichs via Glass]

On 02/08/2017 11:49 AM, Mariano Martinez Peck wrote:
>
>
> On Wed, Feb 8, 2017 at 3:52 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     Mariano,
>
>     The env var  GEMSTONE_GLOBAL_DIR controls the location global
>     `gemstone` directory so it _can_ be changed, but I am not sure
>     that I want to make this a feature of GsDevKit_home.
>
>     If all stones on a machine do not share the locks directory, then
>     a single `gslist` or `stones` will not be able to list all stones
>     that are running on a machine as `gslist` looks in the
>     GEMSTONE_GLOBAL_DIR to see which stones and netldis are running
>     and the `stones` script picks a GemStone product dir and uses that
>     `gslist` command to list the stones running on the machine ...
>
>     If you want to introduce a custom GEMSTONE_GLOBAL_DIR for each
>     stone, you can add that env var to the
>     $GS_HOME/stones/<stone-name>/custom_stone.env file to ensure that
>     GEMSTONE_GLOBAL_DIR is set for all commands.
>
>
> Ok, all above makes sense. Thanks for the explanation.
>
>     `stones -i` can still be used, but you will have to figure out an
>     alternate way to list all stones and netldis running on a single
>     machine as well as a way to see whether a stone and/or netldi is
>     running for a particular stone, but it seems that it can certainly
>     be done ...
>
>
> This is what I don't understand. I was proposing putting 
>  GEMSTONE_GLOBAL_DIR  inside $GS_HOME but still shared for all stones 
> (not per stone). Say I put the following in each 
> $GS_HOME/stones/<stone-name>/custom_stone.env
>
> GEMSTONE_GLOBAL_DIR=$GS_HOME/server/gemstone
>
> Do I understand correctly that, assuming all my stones are managed by 
> gsDevKit_home, then `stones -i` as well as `gslist` would work correctly?

Sorry, I didn't look close enough at what you were proposing ... I 
didn't get past `$GS_HOME/server/stone/xxx` ...

Putting the locks into $GS_HOME/server/locks is definitely more 
practical, but it still involves more moving parts. We'd still not see 
the stones started from a different $GS_HOME directory (yes ... I have 
multiple GS_HOME directories). We'd start running the risk of collisions 
if one happens to create two stones with the same name in different 
GS_HOME locations ... If one were using /etc/services, there's the risk 
of connecting to a stone in a different GS_HOME location as well ... or 
more likely not connecting ...

I know that the multiple GS_HOME location is a limited use case, but 
without expressly forbidding multiple locations it is one more thing 
that could make figuring out problems more complicated ... so I'm still 
not inclined to do this by default.

All of the stones would have to share the setting for 
GEMSTONE_GLOBAL_DIR (putting it in $GS_HOME/bin/defStone.env would do 
the trick --- but you have to do this on a separate branch to avoiding 
polluting the checkin for others) and then the `stones` command would 
still have to be modified to use GEMSTONE_GLOBAL_DIR so that the 
embedded gslist command could find the new location ... but AFAIK that 
is all that would need to be done ...

If we were to add this to GsDevKit_home, I would want to make it an 
install-time option (that's when the /opt/gemstone directory is created) 
.... we'd have to avoid modifying $GS_HOME/bin/defStone.env, so that 
means one more level of indirection to a 
$GS_HOME/sys/local/gsdevkit_bin/defStone.env and that would mean 
modifying $GS_HOME/sys/default/server/gemstone/templates/stone.env to 
look for a $GS_HOME/sys/local/gsdevkit/defStone.env --- not bad. The 
tough one is to get the `stones` command to pick up the proper 
GEMSTONE_GLOBAL_DIR ... given the fact that the definition is in a file 
in $GS_HOME/sys/local the developer will be free to change it's value, 
so presumably we'd have to export 
$GS_HOME/sys/local/gsdevkit/defStone.env in the `stones` command script 
as well --- also doable ...

So that leaves adding the option to installServer and 
installServerClient ... which is also doable ...

Do you think you could put together a pull request with these modifications?

Dale


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170208/1a631873/attachment-0001.html>