Can we move locks to inside GsDevKit_home ?
Locked
Can we move locks to inside GsDevKit_home ?
 
|
Hi Dale,
When we were working together at home during November we discussed about putting each stone lock files inside the $GS_HOME/server/stone/xxx directory. As far as I remember, the conclusion was that the locks directory had to be a centralized repository for all possible stones. Honestly, I find it disturbing having to still need /opt/gemstone/locks while everything is under $GS_HOME. It brings unnecessary sysadmin complications. So I am wondering if locks folder cannot be inside $GS_HOME. For example, what about $GS_HOME/server/locks ? Thanks in advance, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Can we move locks to inside GsDevKit_home ?
|
|
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. `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 ... Dale On 02/08/2017 07:14 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Can we move locks to inside GsDevKit_home ?
|
|
On Wed, Feb 8, 2017 at 3:52 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Ok, all above makes sense. Thanks for the explanation.
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>/ 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?
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Can we move locks to inside GsDevKit_home ?
|
|
On 02/08/2017 11:49 AM, Mariano
Martinez Peck wrote:
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 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Can we move locks to inside GsDevKit_home ?
|
|
On Wed, Feb 8, 2017 at 5:41 PM, Dale Henrichs <[hidden email]> wrote:
OK, I understand that and I agree. So I will try to focus on my case only.
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?
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?
Sorry, but for the moment I am running out of time already. And I still have some issue on the pipeline to provide.... _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Can we move locks to inside GsDevKit_home ?
|
|
On 02/09/2017 04:39 AM, Mariano
Martinez Peck wrote:
right .. 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. I understand ... I'm also busy at the moment:) Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
| Free forum by Nabble | Edit this page |