[Glass] Can we move locks to inside GsDevKit_home ?

Thu Feb 9 04:39:19 PST 2017

On Wed, Feb 8, 2017 at 5:41 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> 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> 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>/c
> ustom_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.
>
>

OK, I understand that and I agree. So I will try to focus on my case only.

> 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)
>

Well, I am not creating stones all the time yet, so I am fine to manually
add the GEMSTONE_GLOBAL_DIR  in custom_stone.
That way I would not even need touching defStone.env right?

> 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 ...
>

This is the part I don't understand. You said *"The env var
GEMSTONE_GLOBAL_DIR controls the location global `gemstone` directory so it
_can_ be changed"*   but now you also say  *"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".  *So why would `stones` be
getting the old/wrong value if I correctly export GEMSTONE_GLOBAL_DIR?
Maybe the code is still hardcoded to /opt/gemstone and not using the
variable?

>
> 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?
>
>
Sorry, but for the moment I am running out of time already. And I still
have some issue on the pipeline to provide....

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170209/b381909d/attachment.html>