250bpm

It is true that 100% of applications need configuration. That being said I am not so sure that every 3rd party component (nn) should have it's own config file. If you look at it from a broader context then you will see that an "application" already has a config file (my case). Introducing nano into the mix would be more difficult if it involved tearing some parts of it out.

If you decide to use the config file approach then I suggest you use coyaml from tailhook. Best I've seen.

Personally, I wouldn't worry too much about pluggable systems to store configuration data. The "public" interface for configuration information can be a configuration file. It works for almost every other system service I work with. I can then use something external (puppet, chef, a bunch of home grown shell scripts talking to MySQL, whatever) to generate that configuration file. Doing it this way neatly decoupling the actual config from the way it's stored and distributed, and means you don't have to care about supporting a whole bunch of extra dependencies.

That said, I think there's a certain elegance to storing the connection information as SRV records in DNS. :) Then you just need to configure applications to look for a well known service name to get the connection details. On the other hand, that's not really flexible enough to distribute anything more than host/port information, so you still need admin configuration files…

On the third hand, nanomsg is fundamentally a library, and it's not the "role" of the library to configure itself. That's the responsibility of the host application it's integrated with. I personally dislike the notion that log4j has its own separate configuration file in every Java app I deploy, for example (while the log4j config format is consistent across apps, the actual configuration data is very app specific, so there's no real benefit to it being in a separate configuration file!). Perhaps the goal of nanomsg is to make the API amenable to easy configuration (though I'm not sure exactly what that means!)?

Anyway, this is random drive-by commenting from an outsider, who doesn't understand the broader conversation, so feel free to take it with a pinch of salt. ;-)

As someone that worked at TIBCO i think it is worth folks looking at FTL in this context. FTL provides a central configuration management solution. This has some very useful applications. However, I also think FTL suffers by not offering a way for customers to configure the library locally.

FTL uses a JSON configuration format. Which I think is a reasonable way to go with nanomsg. The library could provide a simple API for getting that JSON from somewhere else (mongodb, a rest api, a web server, …) as a URL, providing the JSON as a string, or building library elements manually.

If you want to go a step further, FTL provides dynamic updates, where changes made at the central server are pushed out to the clients.

Anyway, I think FTL offers a nice model for this option and is worth looking at.

I'm far from being an expert in configuration management, but i'm quite sure that there are many ways of solving the problem, all better than the others given a particular context (technology, legacy, security, philosophy, corporate guidelines, personnal habits, etc).

I tend to believe that the fewer roles a component has the better it is. Then ability to compose several pieces together at will is Freedom.

I still haven't got time to dive deep into the source of nanomsg, but what appealed to me from the outside was its name, that it is written in c, has minimal api and a modular protocol system.

It would be nice to have another beautiful piece of software dedicated to solve the specific problem of configuring network topologies but I think it should be fully decorelated from nanomsg.

Thanks again for your blog and your work on nanomsg.

I think I tend to agree with the view that nanomsg should be first and foremost a networking library so I'd be hesitant to start blending into it config management. On paper it perhaps looks like a good idea, but my feeling is that it most likely won't fit most people's requirements fully and would suffer dreaded feature creep as a result.

I also disagree with your assertion that admins demand the power to dictate whether sockets are bound or connected. Of course, things like connect addresses, ports, etc should be under the control of admins but it sounds like you'd like to delegate topology decisions and architectural design to a group of people who would perhaps consider it the system developers responsibility to build a sane, fault resistant and scalable system.

This is certainly my experience when building backend systems at scale. I would rather submit a newly developed system that has been architecturally designed against a topology model that's been peer reviewed, than to simply hand over a collection of components and say "we'll, it's up to you now…".

You can use DHCP for this. Check this old (2004) presentation, where Yannick Cadin explains how to use a DHCP server to send configuration to several applications, not only dns config, ip, ntp and other minimal config.

HTH

http://2004.eurobsdcon.org/uploads/media/EBSD04_slides_41.pdf

You can look how sqlite pragmas work. You can configure sqlite at compile time as usual and /or sending pragmas, this manner you can modify threading support, buffer memory, wal mode and a long list of different settings, some of them at running time.

What about testing?

There are (at least) two annoyances in (integration) testing with current networking stacks:

• If you want to run tests in parallel you need to somehow pick an unused port. This is the case even if you're testing different applications (if you're running tests on a CI server, for example) which just happen to use overlapping sets of ports. This is actually a huge annoyance in practice even though it's actually not a theoretically difficult problem by any stretch.
• If you have any even remotely complicated setup you may be forced into setting up your CI build slaves with complicated networking setups.

Given that nanomsg really "just" provides a virtual network on top of IP, it seems to me that omitting a "user provides all configuration" (via files or whatever) option would be a mistake when it comes to testing support. Such configuration would actually also have to be per-context (in ZMQ terminology) to enable parallel testing without spawning multiple instances of the application — usually spawning separate instances of the application would not be a problem, but it is a big problem if you're running with a managed runtime (JVM or .Net equivalent, for example) because of the startup time.

Re: port multiplexing. That's excellent, though the "port" bit is really just a detail — my point is really that if there's some exclusive resource which cannot easily be configured for test setups then that becomes a problem for parallel testing.

I suppose the worst case here really is parallel testing of the same application — let's say we want to run tests for all branches of an application (on push).

The second point basically just goes to the possibility of isolating test configuration from "real" configuration — I think partially related to your point 3 (identification), but a bit broader, I think. Let's assume that I want to run tests for two (or more) applications (in parallel or otherwise) or multiple instances of the same application. Is there some way to have:

• a different setup for each application such that they won't conflict regardless of whatever setup they require (ports, endpoints, etc.)?
• can they run in parallel?
• can I modify the application's networking topology (configuration) without having to reconfigure the (physical) build slaves or messing around with a separate configuration "database" (DNS, DHCP, …)? Ideally, I'd like to be able to bundle the configuration with the code to avoid external dependencies. External dependencies in tests make for very fragile tests in my experience. Building/testing multiple branches of the same application in parallel is also a use case here.
• can I use identical build slaves to run all my tests? (Matters for performance of building/multiple branches of the same application on every checkin.)
• can I avoid nanomsg-specific (manual) setup on my development machine?

AFAICT a simple configuration file (not globally installed) lets one support all of these scenarios, but any kind of "global" configuration (DNS, DHCP, etc.) could place severe limits on what can be done in these cases.

(There's a lot of overlap between these issues and the issues with integration testing against "real" databases.)

Maybe I've just missed something, though. I just wanted to bring your attention to these issues before it's too late :)

Interesting discussion.

In an ideal world, where system administrators are either

A. all doping on happy pills and are highly cooperative or
B. they do not exist

The DNS solution is the best solution i think. Random thought: make a small DNS server available to the app.

Random thought #2

Assuming that either topology could fit into memory, the topology entity should be a data structure (in C) with a CRUD API. Config files or other ways to manage the toplogy would be built on top of the CRUD API. Internally, listener functions will bi-directionally sync the topology data structure with the actual topology of the network. The data structure could also publish changes to an INPROC, IPC, or TCP connection so that you could build real-time visualizations of the topology.

If the fits-in-memory assumption is too strong for your taste, then I vote for DNS or mini-DNS .

Either way, it seems like a separate project from nanomsg.