150 likes | 255 Views
DIRAC Information System. Ian Stokes-Rees. Summary. Service and Agent Configuration Motivation Architecture Example API Service and Agent Monitoring XMPP Asynchronous Messaging Protocol Architecture Messaging Types Current Usage Future Plans. Configuration System: Motivation.
E N D
DIRAC Information System Ian Stokes-Rees
Summary • Service and Agent Configuration • Motivation • Architecture • Example • API • Service and Agent Monitoring • XMPP Asynchronous Messaging Protocol • Architecture • Messaging Types • Current Usage • Future Plans
Configuration System: Motivation • Configuring a large number of distributed services and agents was a complex problem • Required a mechanism that provided • Local configuration • Global configuration • Configuration sharing • Overriding of global settings • Ease of deployment • Ease of updates • Robustness • Simplicity
Service Topology INI INI INI Information Service XML-RPC INI INI Service B Service C Service A Service D Agent X Agent Y
Example: INI Format Section [lbnts2] Modules= JobAgent [Agent] LogFile= agent.log LogOutput= stdout,file LogLevel= DEBUG [JobAgent] CEUniqueIds= in2p3.fr/pbs-short AgentName= TestModularAgent Option Value
Features • Creates image of a single INI file by “merging” local and remote configuration • Warnings are produced for discrepencies between local and remote settings • NOTE: Another Service may expose it’s own details via the remote InformationService API • Service (or Agent) may add, change, or remove a remote Information Service at any time • Currently only supports one remote Information Service • In principal, nothing wrong with ordered list of Information Services to cycle through
API • Simple, but powerful • Based on core Python ConfigParser module • Roughly follows Windows INI format • Base methods • value = get(section,option) • void set(section,option,value) • list = options(section) • list = sections()
XML-RPC Extension • Software instatiates a LocalInformationService: • infoSvc = LocalInformationService([iniFile]) • infoSvc = LocalInformationService(URL) • Any calls to get(…)which do not find a (section,option) pair in the locally loaded information will refer to a remote InformationService XML-RPC server • Local values override remote (global) values • Extended functionality: • void copy(section) • void copyAll() • list = getsection(section)
Code Example [DEFAULT] MasterInfoServiceURL = http://www.example.com:9130 [ServiceA] ServiceName = “The Big A Service” class ServiceA: def __init__(self): otherServices = [‘sB’,’sC’] self.infoSvc = LocalInformationService(‘serviceA.ini’) masterIS = self.infoSvc.get(‘DEFAULT’,’MasterInfoServiceURL’) name = self.infoSvc.get(‘ServiceA’,’ServiceName’) for s in otherServices: self.infoSvc.setIS(master) svcURL = self.infoSvc.get(s,’ServiceURL’) self.infoSvc.setIS(svcURL) self.infoSvc.copy(s) self.connectToService(s)
XMPP for Service and Agent Monitoring • Extensible Messaging and Presence Protocol (XMPP) grew out of Jabber Instant Messaging framework • Provides: • Asynchronous messaging queues • Broadcast messaging • Presence awareness • Publish/Subscribe framework • RPC mechanisms
XMPP Architecture XMPP-Core IETF Draft XMPP-IM IETF Draft Server: routes and buffers messages, handles presence probes S C S Client: thin client, only responsible for processing incoming messages C C C DB C C DB DB: Stores user profiles and rosters
XMPP Architecture (con’t) • Server takes all responsibility • Client only requires “user” to provide authentication details • All other user details are stored on the server • Makes for very light client • <XML> based and Connection based • Client opens an XML stream with Server • Events are passed as XML fragments • Called Stanzas in XMPP parlance
Message Types • XMPP only supports three types of XML Messages: • <message> : push based general communication • Instant message • One to one chat • Group chat (broadcast) • <presence> : availability and status • <iq> : pull based RPC mechanism
Current Usage • DIRAC Services are loosely coupled by using asynchronous event model • Services connect to Jabber server • A service registers message handlers for the various affiliated services • A Service can communicate with other services by sending messages • DIRAC Resiliance to Service Failure • Jabber servers are mature and stable • Queues messages if service unavailable • Service retreives messages on restart
Future Plans • Monitor Agents and Services via XMPP <presence> rosters • Allow Service access via XML-RPC over XMPP • Communicate directly with jobs on WNs via <iq> • Only outbound IP connectivity is required • Messages are tunneled back over open stream • Great potential for interactive jobs