GNU Radio and IceGrid

Tim Newman

The ICE Family

• ICE has more to it than the RPC functionality used in GNU Radio

• ZeroC has also developed a number of services that completely the ICE core Goal is to support distributed applications

• Freeze Object persistence and scripting for database

migration Basically an API for a BerkeleyDB

The ICE Family

• IceStorm Event distribution service Publish-subscribe event distribution service

The ICE Family• Glacier2

An ICE specific firewall traversal service Provides a connection concentrator for the

various ICE ports

The ICE Family

• IcePatch2 A software distribution and patching service Integrated with IceGrid

IceGrid“A grid computing service with features essential for large-scale applications”

- http://www.zeroc.com/services.html

Things that IceGrid Does• Location Service• On-Demand Server Activation• Application Distribution• Replication and Load Balancing• Sessions and Resource Allocation• Automatic Failover• Dynamic Queries• Administration• Deployment

IceGrid Things• Terms I will use that are specific to using

IceGrid with GNU Radio• Node

A hardware computing platform, e.g. a 1U server, a laptop, a USRP E100

• Application Description of the servers, templates, and

endpoints to be deployed• Server

A notation specific to Ice that refers to the entity that basically encapsulates a GNU Radio application

Our server will be called “WaveformBooter”

IceGrid Guts• Consists of a registry and a number of nodes

Cooperate to manage “applications”• Applications assign servers to nodes

Registry maintains persistent record of this info

Nodes responsible for starting and monitoring server processes

• Clients query registry for server endpoints

Ice.ObjectAdapter = communicator().createObjectAdapterWithEndpoints("MyAdapter", "tcp -p 10000");

Ice.ObjectAdapter = communicator().createObjectAdapter(“Object1@MyAdapter");

From To

IceGrid Guts

• Typical configuration A node per computer that manages several server processes

Why do GR developers care?

• In general, enables easier large scale GNU Radio application management

• Users/Developers no longer have to care about the dynamic ICE ports

• GNURadio flowgraphs can be deployed on the “least loaded” hardware resource Dynamic deployment and load balancing!

GNU Radio Grid• What exactly needs to be done in order to make use of all this? Slice interface hooks This is the “middleware language” that ICE speaks Define the XML application descriptor Defines our server templates for IceGrid Create IceGrid config file Start “icegridnode” with config file Add application to the running grid instance

GNURadio Grid• Need a slice interface (This already exists)

/gnuradio-runtime/lib/controlport/frontend.ice

module Booter { dictionary<string, string> WaveformArgs; exception WaveformRunningError { string waveformClass; float centerFrequencyHz; }; exception SignalSourceError {string msg; }; interface WaveformBooter extends Frontend::Receiver, ControlPort { string launchWaveform(string waveformClass, WaveformArgs args) throws WaveformRunningError, SignalSourceError; WaveformArgMap getDriverEnum(); WaveformArgMap getSourceInfo(); idempotent bool waveformRunning(); idempotent string getWaveformClass(); }; };

Slice

GNURadio Grid• Define Application Deployment Descriptor

.

.<server-template id="Waveform::Booter::Generic_T"> <parameter name="index"/> <server id="Waveform.Booter.Generic-${index}" activation="on-demand" exe="python"> <description>Generic booter template</description> <option>master/grbooter.py</option> <adapter name="Booter" endpoints="default" id="${server}.Booter" replica-group="Waveform.Booter.Generic"> <allocatable identity="${server}.Booter" type="::SignalSource::Generic" property="Identity"/> </adapter> <adapter name="ControlPort" endpoints="default" id="${server}.ControlPort" server-lifetime="false"/> </server></server-template>..

XML

The magic happens here

GNURadio Grid• Define IceGrid config file

IceGrid.InstanceName=GrGrid

# The IceGrid locator proxy.Ice.Default.Locator=GrGrid/Locator:default -p 4061 -h $IPADDRESS

# IceGrid registry configuration. IceGrid.Registry.Client.Endpoints=default -p 4061 -h $IPADDRESS IceGrid.Registry.Server.Endpoints=default -h $IPADDRESS IceGrid.Registry.Internal.Endpoints=default -h $IPADDRESS IceGrid.Registry.Data=$GRGRIDWORKINGDIR/db/registry IceGrid.Registry.PermissionsVerifier=GrGrid/NullPermissionsVerifier IceGrid.Registry.AdminPermissionsVerifier=GrGrid/NullPermissionsVerifier IceGrid.Registry.SSLPermissionsVerifier=GrGrid/NullSSLPermissionsVerifier IceGrid.Registry.AdminSSLPermissionsVerifier=GrGrid/NullSSLPermissionsVerifier IceGrid.Registry.DynamicRegistration=1

# IceGrid node configuration. IceGrid.Node.Name=$HOSTNAME IceGrid.Node.Endpoints=default -h $IPADDRESS IceGrid.Node.Data=$GRGRIDWORKINGDIR/db/node IceGrid.Node.CollocateRegistry=1

GNURadio Grid• Start icegridnode

icegridnode --Ice.Config=$GRGRIDWORKINGDIR/$ICECONFIGFILE --daemon --pidfile $DAEMON_PID –nochdir

• On initial creation add application icegridadmin --Ice.Configconfig.grid -r Master –e application add app_description.xml

• That was pretty complex….

Deployment Issues

• Not straightforward to do dynamic off-the-shelf deployment

• IceGrid registry endpoints are required Could be found using 3rd-party service

discovery script• Node endpoints must be specified

At a minimum the IP address(es) of node• Other various parameters that are dynamic

deploy_grid.py

• Simple python script with user prompts for deploying an IceGrid node Prompts user for required information Creates the Ice config file Creates application description xml file Creates init.d script for starting service

Example Applications

• So I have a “gridnode” up. Now what?• Remember the grbooter.py script in the application desciption? This is called when an IceGrid client starts a

server Implements the WaveformBooter class and

implements the interfaces defined in the slice file

Most importantly “launchWaveform”

Example Applications• Pick your IceGrid client language.. • Python –

Get endpoints to IceGrid registry A good chuck of python code should be here Get a list of the nodes and pick one to deploy

on Could use load information to decide

nodes = self.admin.getAllNodeNames()info = self.admin.getNodeInfo(node)

Example Applications• Start the server and launchWaveform!# Generate server instance and startadapterid = "Waveform.Booter.Generic-%s"%(wfid)desc = IceGrid.ServerInstanceDescriptor(template,{'index':wfid})admin.instantiateServer("Grid",node,desc) admin.startServer(adapterid)

# Get reference to the server that was just startedbooter_id = "Waveform.Booter.Generic-%s.Booter"%(wfid)adapter_info = admin.getAdapterInfo(booter_id)constr = communicator.proxyToString(adapter_info[0].proxy).replace('dummy',booter_id)base_prx = communicator.stringToProxy(constr)booter = GNURadio.Booter.WaveformBooterPrx.checkedCast(base_prx)booter = booter.ice_timeout(-1)

# Launch the waveform through IceGrid. Arguments from the URL are passed through.booter.launchWaveform(waveform,arguments)

Now What?

• GNU Radio ICE endpoints are passed to the IceGrid registry

• Add features to gr-ctrlport-monitor Pass registry ip-address as parameter Nodes and running servers can be viewed Endpoints can be retreived using simple adapter names

• Write simple script for starting/stopping basic application via IceGrid hooks Show deploying on multiple nodes Monitor with gr-ctrlport-monitor Imagine a fully integrated application for

starting/stopping and monitoring “lots” of nodes each with many applications running