Ring monitoring interface on every node needed

[GoogleCodeExporter]

Hi!
Is it possible to make that ring monitoring interface worked on each node (not 
just on boot-node)? This is necessary for the case when the boot-node is down.

Thanks.

Original issue reported on code.google.com by serge.po...@gmail.com on 6 Aug 2010 at 11:05

[GoogleCodeExporter]

You could restart the boot-node and the other nodes will eventually reregister 
with the boot-server (see {reregister_interval, 600000} in scalaris.cfg and 
dht_node_reregister.erl). 

However, you have to make sure that when you restart the boot-server that you 
change "-boot_cs first true" to "-boot_cs first false" in scalarisctl!!! 
Otherwise it will start a new ring.

Scalaris is supposed to be a peer-to-peer system where every node knows just a 
couple of other nodes but not all other nodes. We introduced the boot-server to 
make debugging easier and early versions of Scalaris relied on the boot-server 
for joining new nodes.

To show the ring monitoring interface you have to know all nodes in the system. 
We are not planning to add a boot-server to each scalaris-node.

Original comment by schu...@gmail.com on 6 Aug 2010 at 12:07

[GoogleCodeExporter]

Ok. I see. Would you like to implement a separate node for administrative 
purposes? This would serve all nodes with the data without losing the 
capabilities of monitoring. A stop/failure of this node would not affect the 
functionality of the database.

Original comment by serge.po...@gmail.com on 6 Aug 2010 at 12:34

[GoogleCodeExporter]

You are describing essentially our boot-server. All nodes report periodically 
to the boot-server and you can see the ring monitoring interface on its 
webserver.

But in your first message, you said that you were considering the scenario 
where the boot-server is down. So the other nodes could not contact the 
boot-server to get the list of nodes.

Original comment by schu...@gmail.com on 6 Aug 2010 at 3:11

[GoogleCodeExporter]

I mean the fully separation of the admin-node from any data-manipulation 
functions, and so one can stop also the boot-node (which only used now for data 
manipulation proposes) for a maintenance.

Original comment by serge.po...@gmail.com on 6 Aug 2010 at 3:27

[GoogleCodeExporter]

I am confused. For historical reasons ./boot.sh starts an Erlang VM with two 
components:
- boot_server.erl: the so called boot-server and
- a scalaris node
Formerly the boot-server was required to add new nodes to the system. Thatswhy 
it is called the boot-server. Today the boot-server maintains a list of the 
scalaris nodes in the system and provides a web-interface for debugging.

By playing with the command line parameters ("-boot_cs first true") you could 
build a scalaris ring without ANY boot-server. Or you could have ./boot.sh 
start an Erlang VM with the boot-server but without any scalaris nodes. In the 
latter case you can restart ./boot.sh without affecting the system at all. 
(Each scalaris node periodically reports to the boot-server or to a list of 
nodes configured with {register_hosts, []} in scalaris.cfg.)

My point is that the boot-server has no administrative tasks. It is only for 
data-manipulation as you said.

However, when starting a scalaris ring we have to mark exactly one node as the 
first node. We are currently using a command line parameter "-boot_cs first 
true" to mark the scalaris node started by boot.sh as being the first (see 
dht_node:init). In a similar manner you could use a ./cs_local_first.sh to 
start a scalaris node marked as first. This ring would run without any 
boot-server.

Original comment by schu...@gmail.com on 9 Aug 2010 at 10:59

[GoogleCodeExporter]

Ok. I request for three start scripts:
1. For first scalaris data node.
2. For ordinary scalaris data node.
3. For admin-node which "maintains a list of the scalaris nodes in the system 
and provides a web-interface for debugging".

>Today the boot-server maintains a list of the scalaris nodes in the system and 
provides a web-interface for debugging.

>My point is that the boot-server has no administrative tasks. It is only for 
data-manipulation as you said.

I think that is a contradiction in these phrases... Or not?

Original comment by serge.po...@gmail.com on 9 Aug 2010 at 11:45

[GoogleCodeExporter]

see r981:

1. For first scalaris data node.
scalarisctl -i -f node start
2. For ordinary scalaris data node.
scalarisctl -i node start
3. For admin-node which "maintains a list of the scalaris nodes in the system 
and provides a web-interface for debugging".
scalarisctl -i -e boot start

-f means first and -e means empty

> >My point is that the boot-server has no administrative tasks. It is only for 
data-manipulation as you said.
> I think that is a contradiction in these phrases... Or not?
Sorry. That sentence was misleading.

Original comment by schu...@gmail.com on 12 Aug 2010 at 1:00

[GoogleCodeExporter]

Hi!
It seems that it works like as I want. Thanks.

PS: 
The case when no one node is in the ring should be provided in the monitoring 
interface.
PSPS:
Example scripts should be adapted. I propose next list of scripts:
1. admin.sh - for start an admin node.
2. boot.sh - for start a first/boot node.
3. cs_local0.sh - for restart boot node.
4. cs_localX.sh - for start ordinary nodes.

Original comment by serge.po...@gmail.com on 12 Aug 2010 at 1:44

[GoogleCodeExporter]

I rather keep the scripts as they are. For new users, running boot.sh gives 
them a complete Scalaris system with the web interface and one node. Only once 
you know what you are doing, you will think about separating the roles.

I will fix the web interface for 0 nodes.

Original comment by schu...@gmail.com on 13 Aug 2010 at 8:55

[GoogleCodeExporter]

> I rather keep the scripts as they are. 
Ok. Maybe worth while to add a description of the new opportunities and the 
case when it may need to the FAQ and/or to the scalaris user guide?

>I will fix the web interface for 0 nodes.
Thanks

Original comment by serge.po...@gmail.com on 13 Aug 2010 at 10:07

[GoogleCodeExporter]

I updated the FAQs in r1082 - everything else has already been fixed, afaik

Original comment by nico.kru...@googlemail.com on 1 Sep 2010 at 3:26

• Changed state: Fixed