[Glass] Can we move locks to inside GsDevKit_home ?

Thu Feb 9 08:28:38 PST 2017


On 02/09/2017 04:39 AM, Mariano Martinez Peck wrote:
>
>
> On Wed, Feb 8, 2017 at 5:41 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto: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
>>     <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.
>
>
>
> 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?
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?
No, I'm referring to the fact that the `stones` command itself does not 
run within the context of a particular stone (i.e., there is no 
defStone,env to be sourced), so even if you've got /GEMSTONE_GLOBAL_DIR 
in all of the custom_stone.env for your stones, you will still have to 
"do something" to export the proper value of //GEMSTONE_GLOBAL_DIR when 
you run the `stones` command.... You could arrange to do this multiple 
ways, but you do have to arrange to do this.
/
>
>
>     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....
>
I understand ... I'm also busy at the moment:)

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170209/46cf0b48/attachment-0001.html>