On Wed, 15 Nov 2017 15:30:37 +0100
MarLinn
Hi Alex,
sounds ambitious. But you might be able to reduce the scope massively by relying on existing tools.
Yes! I do not wish to reinvent the wheel.
Examples:
*
Let something like Nagios do the monitoring. I know there's tools to control Nagios from Haskell. What I don't know is how up-to-date they are, and I haven't seen something that reports internal performance data of a Haskell app to Nagios, but that should be simple if necessary.
I don't think Nagios is a good fit because I want to do more than monitor the performance of the interpreter. I want to rely on that performance data so that I can use resources more effectively. For example, I want to know what the load average of a particular node is, and then I want to rely on historical performance data of the DSL primitives to determine if the next instruction to be executed should be scheduled to run on that node or a different one.
*
Let something like Cassandra handle both the heaviest parts of messaging between your node controllers and the storage of their config data. If you base your WUI on top of the DB, you can separate it from the controllers as well.
*
Coordination of resources is a variant of scheduling, which is a ""solved"" problem. So there should be libraries you can use.
For cluster coordination/configuration I was thinking of using Consul.
*
Logging has been worked on by many a commercial Haskeller. My guess is that filtering is just a matter of looking at one of the libraries from the right angle.
I intend to leverage existing libraries where possible. I want to create an environment in which the commercial Haskeller never has to choose and wire in a logging library. The decision is already made by the framework. They just need to insert logging statements where appropriate.
Or just use Kubernetes. Whichever is easier. ;)
Kubernetes is a great tool, but it doesn't do what I envision. -- Alex