Can we move locks to inside GsDevKit_home ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we move locks to inside GsDevKit_home ?

GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Can we move locks to inside GsDevKit_home ?

GLASS mailing list

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


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can we move locks to inside GsDevKit_home ?

GLASS mailing list


On Wed, Feb 8, 2017 at 3:52 PM, Dale Henrichs via Glass <[hidden email]> 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?

Dale


On 02/08/2017 07:14 AM, Mariano Martinez Peck via Glass wrote:
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


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can we move locks to inside GsDevKit_home ?

GLASS mailing list



On 02/08/2017 11:49 AM, Mariano Martinez Peck wrote:


On Wed, Feb 8, 2017 at 3:52 PM, Dale Henrichs via Glass <[hidden email]> 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



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can we move locks to inside GsDevKit_home ?

GLASS mailing list


On Wed, Feb 8, 2017 at 5:41 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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?

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



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can we move locks to inside GsDevKit_home ?

GLASS mailing list



On 02/09/2017 04:39 AM, Mariano Martinez Peck wrote:


On Wed, Feb 8, 2017 at 5:41 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass