[nanomsg] Re: Rules-based topology description
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 20 Sep 2013 08:40:57 +0200
Hi Paul,
Wow! I mean WOW!
I've always thought of this in terms of mechanism/policy separation
(programmer vs. admin) but I have never though of adding modularity to
the mix.
This increases the power of the solution by a whole order of magnitude.
In fact, it rivals most powerful configuration systems out there
(including in big banks, telcos and such). Actually, "surpasses" may be
a better word than "rivals". If you were IBM, you would be selling it
for millions of dollars per datacenter :)
Couple of remarks:
Firs, I would suggest calling is a "configuration service". Using "name
service" for this kind of thing is stretching the semantics way too far.
2. I'll probably cut down the NS protocol to (<url> <socket_type>)
pairs. All additional data can be specified in url as query parameters
("?name=value")
Nice and simple. I like it.
3. I don't believe that applications would live without the name of
the topology in configuration files. E.g. if there is an image
resizing service. It could join the topology with the name
"image-resizer". But in reality it will join the topology as
"image-resizer.mywebsite.com" for two reasons:
3a) I might run same service for multiple projects
3b) I would like my development cluster's "image-resizer" service to
be unable to connect to production cluster, even if I make a mistake
+1 for fully qualified topology names.
5. As you can see in the pictures, it's possible to draw the full
topology graph based on the name service's requests only. The only
piece left is the nodes that are dead after making name request. That
would be provided by monitoring system.
I would be cautious about that. NS requests can (at least in theory)
originate from different sources, including management tools and such.
That would mess up the pictures. I would say the monitoring service is
the way to go.
As discussed on IRC we will provide the separate library called
"nanoconfig" that
is built on top of nn_connect()/nn_bind() API that does name service
requests. It will live outside of the core until the semantics and
protocol are stable enough and match everybody's expectations. We will
encourage language bindings to support nanoconfig out of the box.
Yes. This seems to be an even better option now. First, I would like you
to be in full control of the project, given that you've proved to have
better understanding of the problem than I do. (I would like to help
with it though.) Additionally, it allows you to proceed at the full
speed without being hindered by backward-compatibility concerns of
nanomsg itself.
The "rulens" service will be rewritten in C to be easier to setup. So
I'm much interested in discussing configuration file format and
semantics, but not the real implemenation.
I don't have much to say configuration format. Probably just go with
whatever the most admins would consider "familiar", "easy to grasp" etc.
Martin
Other related posts:
