WMS:Design

From CTWUG Wiki
Revision as of 23:38, 8 November 2012 by Mufasa (talk | contribs)

Jump to: navigation, search

Initial design ideas. Please discuss and add ideas in your own colour! Note your colour here:

Aragon
Mufasa

SCRIPTS

WMS will be script oriented, where scripts are almost like apps, and WMS is like an app market to/from which wuggers can share and run apps. Scripts would be written in whatever language their target architecture uses - ROS scripting for MT devices, Bourne shell and PHP for UBNT, etc. and WMS should have mechanisms to prevent scripts of ROS architecture from running on UBNT devices.

The scripts would also be fed through a server-side template processor, so that when a wugger assigns a script to run on his RBs, he can also define run parameters. The run parameters would be used by the template processor when serving the script up to the wugger's RB.

The script store I think should be centralised, but they'd be mostly static objects that could be easily cached and distributed. The reason for making it centralised is so that all wuggers can share to/from a common script pool, in the hope this drives scripting standards. Essentially the WMS "master" that hosts all the scripts would be a very small webapp that wouldn't do much, and so can be erected elsewhere quickly if the need arises.


WUGGER ACCESS

Wuggers would administer WMS by logging into their own local WMS "slave" server. The slave servers would query the central master for script information, but when it comes to defining run parameters and router devices, that gets done and stored on the slaves. When routers are added to WMS, they'd communicate with the slave local to their area/district.


SCRIPT EXECUTION

Each router device would need some kind of bootstrap manually loaded onto it, a script/app written for the device's architecture that polls WMS for work in a standard way. In the slave WMS interface, wuggers would assign script execution to routers by CIDR mask, and WMS should be able to handle cascaded definitions, for example:

Script "A" is assigned to 172.18.87.0/24 for execution with parameters "X". Script "A" is again assigned to 172.18.87.1/32 with parameters "Y", and script "B" assigned to 172.18.87.1/32 with parameters "Z". When 172.18.87.1 asks for work, it gets scripts A and B with parameters Y and Z respectively. When 172.18.87.2 asks for work, it gets script A with parameters X only.

Licensing of code/scripts contributed

Code committed to WMS and scripts added should be remain the property of the project and available to the devs without modifications.