netldi for parallel installation glass / maglev
Norbert Hartl
I subscribed a longer time ago to this mailing list but ignored postings until today :) As soon as I started to read I felt the need to install maglev. I'm really impressed by the way it works (I mean how easy).
I think now is the time to start learning ruby (well, chef/vagrant forced me a bit, too). Anyway, as my heart belongs to smalltalk I need to run installations in parallel.
In the installation I saw things like netlid rushing by on the console. So, I want to know how to do a parallel installation. Is it ok to share netldi (I think they don't differ between glass and maglev)? Or is it better to chose different ports and run on netldi for each installation?
A second question is about install location. I see that rvm installs everything into my home directory/.rvm which is ok to start but want work later on. What would be a "central" installation for deployment?
thanks in advance,
Norbert
Norbert Hartl
Norbert
> --
> You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
> To post to this group, send email to maglev-d...@googlegroups.com.
> To unsubscribe from this group, send email to maglev-discuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/maglev-discussion?hl=en.
>
Peter McLain
On Nov 10, 2011, at 3:01 PM, Norbert Hartl wrote:
> Hi,
>
> I subscribed a longer time ago to this mailing list but ignored postings until today :) As soon as I started to read I felt the need to install maglev. I'm really impressed by the way it works (I mean how easy).
Thanks!
> In the installation I saw things like netlid rushing by on the console. So, I want to know how to do a parallel installation. Is it ok to share netldi (I think they don't differ between glass and maglev)?
The executable is the same, but MagLev runs with GEMSTONE_GLOBAL_DIR=$MAGLEV_HOME, so a MagLev netldi will not see a GemStone/S installed in /opt/gemstone (at least not by default). We were trying to ensure there would be no confusion between maglev stones and smalltalk stones. There is nothing in principle that would be a problem to run one netldi and talk with both maglev and smalltalk stones, but you'll have to set that up yourself.
> Or is it better to chose different ports and run on netldi for each installation?
That is the easiest way.
> A second question is about install location. I see that rvm installs everything into my home directory/.rvm which is ok to start but want work later on. What would be a "central" installation for deployment?
In *my* opninion, the rvm install is good for kicking the tires, but I almost always run off a separate install that I manage myself. Follow the github install instructions and put it where you like: http://maglev.github.com/docs/download.html#install_from_github
--
Peter McLain
pmc...@vmware.com
Peter McLain
On Nov 10, 2011, at 3:22 PM, Norbert Hartl wrote:
> To continue this. I just recognized that there is no netldi running. I figured it out because I tried to use the GemTools-Maglev app and it can't find the stone. There should be a netldi, right?
cd $MAGLEV_HOME
rake netldi:start
The default startup for maglev doesn't require netldi.
--
Peter McLain
pmc...@vmware.com
Monty Williams
MagLev defaults to using $MAGLEV_HOME/locks & $MAGLEV_HOME/log. Logfiles in $MAGLEV_HOME/log are always from that one specific MagLev instance. $MAGLEV_HOME/locks ensures "maglev status" only reports status for that one specific MagLev instance. You can delete those locks and logs without disrupting any GemStone/S operations. Pretty handy for us because we run lots of both on shared machines.
$MAGLEV_HOME/setupLocks.sh will link those directories to /opt/gemstone/locks and /opt/gemstone/log, which is what GemStone/S uses. Then "maglev status" will show any running GemStone/S status, including MagLev.
$ maglev status
MAGLEV_HOME = /grace3/users/monty/MagLev/MagLev-27184.SunOS-i86pc
Status Version Owner Pid Port Started Type Name
------- --------- --------- ----- ----- ------------ ------ ----
OK 3.0.1 bille 26395 10067 Oct 18 14:41 Netldi ldibille
OK 2.4.5 akogan 12816 10543 Nov 10 10:25 Netldi ldiakogan
exists 2.4.5 akogan 12824 56873 Nov 10 10:25 Stone akogan64bit24x
OK 2.4.5 normg 15889 10117 Aug 30 08:13 Netldi ldinormg
OK 3.0.1 bille 26553 63922 Oct 18 14:42 Stone sgbj26403stone
OK 3.1.0 bretlb 10531 57277 Nov 08 15:18 Netldi ldibob-3.1.0
frozen 2.4.5 bretlb 1480 48342 Nov 09 17:24 Stone slob10137stone
OK 3.1.0 bretlb 26932 54460 Nov 08 17:39 Stone sgci26877stone
OK 3.0.1 bille 26554 63914 Oct 18 14:42 cache sgbj26403stone~fafc5df1c6e84f65
OK 3.0.1 buildgss 7729 57544 Oct 28 12:24 Netldi fastldibuildgss7636
OK 2.4.5 bretlb 10615 61443 Nov 09 09:57 Netldi ldibob-2.4.5
OK 3.1.0 bretlb 20830 61511 Nov 09 23:29 Stone sgci20775stone
OK 2.4.5 akogan 12825 56865 Nov 10 10:25 cache akogan64bit24x@grace
OK 3.1.0 bretlb 26933 54442 Nov 08 17:39 cache sgci26877stone~fafc5df1c6e84f65
OK 3.1.0 monty 13493 57297 Nov 10 16:15 Stone maglev
OK 2.4.5 bretlb 1481 48318 Nov 09 17:24 cache slob10137stone@grace
OK 3.1.0 monty 13494 57289 Nov 10 16:15 cache maglev~fafc5df1c6e84f65
OK 3.1.0 bretlb 3470 56780 Nov 10 06:52 Stone saddind26928stone
OK 3.1.0 bretlb 20831 61503 Nov 09 23:29 cache sgci20775stone~fafc5df1c6e84f65
OK 3.1.0 bretlb 18766 60691 Nov 09 00:18 cache PID23846~fafc5df1c6e84f65
OK 3.1.0 bretlb 18733 60709 Nov 09 00:18 Stone PID23846
OK 3.1.0 bretlb 3486 56772 Nov 10 06:52 cache saddind26928stone~fafc5df1c6e84f65
OK 3.1.0 bretlb 17453 55658 Nov 10 05:54 cache PID2695~fafc5df1c6e84f65
OK 3.1.0 bretlb 17452 55666 Nov 10 05:54 Stone PID2695
Other differences - MagLev netldi defaults to port 50378, while GemStone/S typically uses port 50377. Both use the name gs64ldi in /etc/services, but it's pretty easy to change the one used by GemStone/S to a different name.
Last but not least, MagLev is running GS/S 3.1, which has some features beyond GS/S 3.0.1
Regards,
Monty
Norbert Hartl
In *my* opninion, the rvm install is good for kicking the tires, but I almost always run off a separate install that I manage myself. Follow the github install instructions and put it where you like:http://maglev.github.com/docs/download.html#install_from_github
Norbert Hartl
Am 11.11.2011 um 01:20 schrieb Monty Williams:
> Hi Norbert,
>
> MagLev defaults to using $MAGLEV_HOME/locks & $MAGLEV_HOME/log. Logfiles in $MAGLEV_HOME/log are always from that one specific MagLev instance. $MAGLEV_HOME/locks ensures "maglev status" only reports status for that one specific MagLev instance. You can delete those locks and logs without disrupting any GemStone/S operations. Pretty handy for us because we run lots of both on shared machines.
>
indeed. On my server I would like to have the same.
Great, I knew it would work.
> Other differences - MagLev netldi defaults to port 50378, while GemStone/S typically uses port 50377. Both use the name gs64ldi in /etc/services, but it's pretty easy to change the one used by GemStone/S to a different name.
>
To be honest I think gs in gs64ldi stands for GemStone, right? I would move the maglev one to something like ml64ldi. Wouldn't disturb any existing GemStone version.
I checked my /etc/services right now and it is gs64ldi 50377. If you are saying that maglev uses 50378 then there could be a step in the install that skips the step if the entry is present. But then it needs to be documented because all smalltalker will fall into this, right?
> Last but not least, MagLev is running GS/S 3.1, which has some features beyond GS/S 3.0.1
>
Oh, I'm relaxed. Until I find the time and get it up and running etc. GemStone and MagLev might use the same version 4.2 ;)
Thanks for the details,
Norbert
Monty Williams
> indeed. On my server I would like to have the same.
$MAGLEV_HOME/setuplocks.sh was created to make that simple.
> Great, I knew it would work.
> To be honest I think gs in gs64ldi stands for GemStone, right? I
> would move the maglev one to something like ml64ldi. Wouldn't
> disturb any existing GemStone version.
You can run MagLev using a different netldi by setting an environment
variable
$ export gs64ldi=maglevldi
and starting the stone with
$ rake maglev:start[maglevldi]
See https://github.com/MagLev/maglev/blob/master/docs/remote-stone.rdoc
for details.
We intended to switch the MagLev netldi to be maglevldi at one point,
but it wasn't quite as trivial as we'd thought. If anyone wants
to tackle it, just do it on a topic branch and send us a pull
request.
> I checked my /etc/services right now and it is gs64ldi 50377. If you
> are saying that maglev uses 50378 then there could be a step in the
> install that skips the step if the entry is present. But then it
> needs to be documented because all smalltalker will fall into this,
> right?
The install script won't overwrite the /etc/services file. So if
you have 50377 already, MagLev will use that port.