As a part of April 4 NDS workshop demo story board.
- Background
A tool: a Clowder extractor, or a Polyglot software server. - Where data are – MongoDB.
In each checking iteration, the elasticity module writes the following info into MongoDB, along with the timestamp:- for each queue: the queue name, number of messages published/delivered, consumer IP, number of instances on each consumer IP (in the 'extr' Mongo collection);
- for each cloud VM: VM name, IP, status, status to transition to if any (in 'cloud_vm');
- for each VM running tools: IP, number of CPUs, load average (in 'vm_info'); the tools running on it (in 'vm2ets');
- the elasticity actions taken: add/remove tool instances, suspend/resume VMs, start VMs, ...
- Interaction with the elasticity module
- Currently the above data are written into MongoDB, so the program for the . The monitoring page can directly connect to MongoDB to get and display the info. So, for For READ-ONLY features, this page can reside anywhere.
- However, currently we are implementing deploy/stop tool features in Tool Catalog, using RabbitMQ queues to communicate between Tool Catalog and the Elasticity Module.
If we want to add editing features into the monitoring page, or on the same site where the monitoring page is, such as deploy, stop, increase/decrease the number of instances – which could be anticipated – we need to consider it together with TC/EM integration, to see whether doing it in TC would be good.
- Options:
- Tool Catalog (likely with Scala, JavaScript).
Pro: implement at a single place, Con: not sure whether it's a good fit. - Brown Dog machine or other web sites, using any language: PHP, JavaScript, ...
Pro: may fit better for fast user interaction.
Con: if implement deploy/stop/increase/decrease later, then duplicated efforts as done in TC. Yet another web app. - Others?
- Tool Catalog (likely with Scala, JavaScript).
- Your suggestions/comments are much appreciated!