|This page describes a CI prototype. It provides a high-level "storyboard" describing intent and expected content for a R2I2 prototype. It also describes prototype design, results and open issues.|
See the Prototyping page for a list of all prototypes.
|Lead||Tim Freeman, John Bresnahan|
|Description||Investigate licensing solutions to run Matlab in a cloud (in general we will need to develop and prototype any "quirks" associated with execution engines).|
|Risks||2317 Cloud Computing Strategy|
Licensing solutions to run Matlab in a cloud (in general we will need to develop and prototype any "quirks" associated with execution engines).
It appears that one of the Execution Engines we will be dealing with is Matlab – this is a licensed technology and can be run in the clouds but (last time I looked) requires a private network connection to a license server. I would like my team to have it "go through the fingers" at least once before integrating it into the design and understand the issues involved in running this for a larger community, at scale, and on a long-term basis. The outcome of this prototype will be mostly experience and a "small example".
The scope is to basically take matlab, read instructions, set up a VM on EC2 and get it to work with the license server that we will be using -- just to go through the process and have the opportunity to notice what we might potentially have there that might affect anything we'll be doing (e.g., if there are special configuration steps connected to standing up a VM running matlab)
The figure below shows the big picture. Matlab should be embedded within one type of execution engine among many to perform real-time data stream processing. It is expected that some Python process in a PyCC deals with the messaging and executes/feeds the Matlab process/processes on one Operation Unit.
The figure below illustrates in more detail the various interacting components of Execution engines in general and for the Matlab case (see lower right). The "Matlab Execution Engine" should in the end be based on an EPU with many Matlab OU instances satisfying the process execution needs. Potentially elastic policy.
- Find out how Matlab can be "embedded" as an Execution Engine and how to deal with the license acquisition issues
- Stimulate design discussions of how data stream processing can be architected for R2, with execution engines, process management, resource agents, governance interactions
- Start thinking towards managing execution resources (VMs, Subscriptions, Licenses, Execution Engines, Processes=Matlab scripts) under the umbrella of a CEI resource management framework
- Collect any design drawings and meeting notes
- Provide input for architects to update use cases and architecture specs
- Munindar and team have an existing prototype for how to describe and implement the interactions in a distributed system. Concepts are: Matab, license broker, license resource provider etc.
Resource Life Cycle
- Might be able to apply the ideas and code of Instrument Agent interface and implementation with device life cycle
Might be able to discuss with Munindar's team about working with a Matlab license server as they have done some previous work with this.
The findings of this prototype work have been documented here: Matlab, Firewalls, and Execution Engines